[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: i960-* and b.out
From: |
Ralf Corsepius |
Subject: |
Re: i960-* and b.out |
Date: |
13 Sep 2002 15:29:18 +0200 |
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