autoconf-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: i960-* and b.out


From: Akim Demaille
Subject: Re: i960-* and b.out
Date: 13 Sep 2002 16:06:09 +0200
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Honest Recruiter)

| 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).

Bwahahaha!

configure:2021: checking for C compiler default output
configure:2024: i960-rtems-gcc    conftest.c  >&5
configure:2027: $? = 0
configure:2056: result: conftest.c

Well, yes, a fix is definitely needed...

How about this one?

Index: ChangeLog
from  Akim Demaille  <address@hidden>

        i960 compilers create `b.out' files by default.
        Reported by Ralf Corsepius.

        * lib/autoconf/lang.m4 (_AC_COMPILER_EXEEXT): Remove b.out files.
        (_AC_COMPILER_EXEEXT_DEFAULT): Adjust to b.out.

Index: lib/autoconf/lang.m4
===================================================================
RCS file: /cvsroot/autoconf/autoconf/lib/autoconf/lang.m4,v
retrieving revision 1.157
diff -u -u -r1.157 lang.m4
--- lib/autoconf/lang.m4 13 Sep 2002 07:18:15 -0000 1.157
+++ lib/autoconf/lang.m4 13 Sep 2002 14:09:43 -0000
@@ -426,6 +426,10 @@
 # _AC_COMPILER_EXEEXT_DEFAULT
 # ---------------------------
 # Check for the extension used for the default name for executables.
+#
+# We do this in order to find out what is the extension we must for
+# compiling executables (see _AC_COMPILER_EXEEXT's comments).
+#
 # 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.
@@ -447,18 +451,29 @@
 # 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
+# b.out is created by i960 compilers.
+for ac_file in a_out.exe a.exe conftest.exe a.out conftest a.* conftest.* b.out
+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;;
+    _AC_COMPILER_EXEEXT_REJECT )
+        ;;
+    conftest.$ac_ext )
+        # This is the source file.
+        ;;
+    [ab].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,
+        # but it would be cool to find out if it's true.  Does anybody
+        # maintain Libtool? --akim.
+        export ac_cv_exeext
+        break;;
+    * )
+        break;;
   esac
 done],
       [echo "$as_me: failed program was:" >&AS_MESSAGE_LOG_FD
@@ -546,10 +561,10 @@
 m4_define([_AC_COMPILER_EXEEXT],
 [AC_LANG_CONFTEST([AC_LANG_PROGRAM()])
 ac_clean_files_save=$ac_clean_files
-ac_clean_files="$ac_clean_files a.out a.exe"
+ac_clean_files="$ac_clean_files a.out a.exe b.out"
 _AC_COMPILER_EXEEXT_DEFAULT
 _AC_COMPILER_EXEEXT_WORKS
-rm -f a.out a.exe conftest$ac_cv_exeext
+rm -f a.out a.exe conftest$ac_cv_exeext b.out
 ac_clean_files=$ac_clean_files_save
 _AC_COMPILER_EXEEXT_CROSS
 _AC_COMPILER_EXEEXT_O




reply via email to

[Prev in Thread] Current Thread [Next in Thread]