Re: i960-* and b.out

[Ralf Corsepius]

Am Fre, 2002-09-13 um 14.19 schrieb Akim Demaille:
> 
> | Am Fre, 2002-07-26 um 18.59 schrieb Jim Wilson:
> | > >I know that unfortunately a lot of i960 tools defaulted to b.out
> | > >for the default name but this oddity is causing unnecessary
> | > >issues with at least the RTEMS configurery.
> | The problem that hits RTEMS actually is an autoconf problem: 
> | autoconf > 2.13 tries to guess on EXEEXT by compiling a c-file without
> | any compiler argument: $CC conftest.c
> | 
> | Using i960-*-gcc's in autoconfiscated source-trees, this leaves b.outs
> | around each time a configure-script is run (Autoconf considers 'a.out'
> | and cleans them up).
> | 

> | > Changing it would mean a minor incompatibility with the Intel GNU960 tools
> | > which they still distribute, and which will continue to emit b.out files.
> | > There are probably b.out file name assumptions in a few other misc places,
> | > like dejagnu, and probably in some other embedded OSes also.
> | >         http://developer.intel.com/design/i960/patches/index.htm
> | If I read all this correctly, it isn't only i960-*-gcc which produces
> | 'b.out', but other i960-compilers do so, too.
> | 
> | => autoconf probably needs to be extended.
> 
> I suppose it should.  But is it possible to see the config.log? 

Yes, cf. the attachment
> I would like to understand how autoconf managed to find the objext:
I don't know (actually I haven't tried to analyze the details yet).

> ----------------------------------------------------------------------
> # _AC_COMPILER_EXEEXT_DEFAULT
> # ---------------------------
> # Check for the extension used for the default name for executables.
> # Beware of `expr' that may return `0' or `'.  Since this macro is
> # the first one in touch with the compiler, it should also check that
> # it compiles properly.
> #
> # On OpenVMS 7.1 system, the DEC C 5.5 compiler when called through a
> # GNV (gnv.sourceforge.net) cc wrapper, produces the output file named
> # `a_out.exe'.
> m4_define([_AC_COMPILER_EXEEXT_DEFAULT],
> [# Try to create an executable without -o first, disregard a.out.
> # It will help us diagnose broken compilers, and finding out an intuition
> # of exeext.
> AC_MSG_CHECKING([for _AC_LANG compiler default output])
> ac_link_default=`echo "$ac_link" | sed ['s/ -o *conftest[^ ]*//']`
> AS_IF([AC_TRY_EVAL(ac_link_default)],
> [# Find the output, starting from the most likely.  This scheme is
> # not robust to junk in `.', hence go to wildcards (a.*) only as a last
> # resort.
> 
> # Be careful to initialize this variable, since it used to be cached.
> # Otherwise an old cache value of `no' led to `EXEEXT = no' in a Makefile.
> ac_cv_exeext=
> for ac_file in a_out.exe a.exe conftest.exe a.out conftest a.* conftest.*; do
>   test -f "$ac_file" || continue
>   case $ac_file in
>     _AC_COMPILER_EXEEXT_REJECT ) ;;
>     a.out ) # We found the default executable, but exeext='' is most
>             # certainly right.
>             break;;
>     *.* ) ac_cv_exeext=`expr "$ac_file" : ['[^.]*\(\..*\)']`
>           # FIXME: I believe we export ac_cv_exeext for Libtool --akim.
>           export ac_cv_exeext
>           break;;
>     * ) break;;
>   esac
> done],
>       [echo "$as_me: failed program was:" >&AS_MESSAGE_LOG_FD
> cat conftest.$ac_ext >&AS_MESSAGE_LOG_FD
> AC_MSG_ERROR([_AC_LANG compiler cannot create executables
> check `config.log' for details.], 77)])
> ac_exeext=$ac_cv_exeext
> AC_MSG_RESULT([$ac_file])
> ])# _AC_COMPILER_EXEEXT_DEFAULT
> ----------------------------------------------------------------------
> 
> 
> How did this work???  What patch would you suggest? 
I am not sure, but wouldn't a plain 
s/a\.out /a.out b.out/g 
in all autoconf's sources work?

Ralf

config.log
Description: Text document