| 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).
|
| > > Is there an easy
| > >way to change this so it defaults to a.out like everything else?
| > >Would this cause grief?
| >
| > Intel changed the a.out object file format, called the result b.out, and then
| > changed the output file name to b.out to make it clear that it wasn't an a.out
| > file. However, there was never any real need to do that, since we use the
| > file name a.out for COFF and ELF without trouble.
| >
| > See OBJ_DEFAULT_OUTPUT_FILE_NAME in gas/config/obj-bout.h. This is the only
| > file that uses that macro. We could just eliminate the macro to solve the
| > problem.
| >
| > 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? I
would like to understand how autoconf managed to find the objext:
----------------------------------------------------------------------
# _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? Thanks!
