autoconf-patches
[Top][All Lists]
Advanced

[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: 14 Sep 2002 06:45:22 +0200

Am Fre, 2002-09-13 um 16.06 schrieb Akim Demaille:
> 
> | 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?
With this patch applied, autoconf-2.54 gets the correct "default output"
and the correct OBJEXT, but is wrong on EXEEXT in all 'empty'-EXEEXT
cases:

* Native (i686-pc-linux-gnu/gcc-3.2):

configure:2101: checking for C compiler default output
configure:2104: gcc    conftest.c  >&5
configure:2107: $? = 0
configure:2152: result: a.out
configure:2157: checking whether the C compiler works
configure:2163: ./a.out
configure:2166: $? = 0
configure:2181: result: yes
configure:2188: checking whether we are cross compiling
configure:2190: result: no
configure:2193: checking for suffix of executables
configure:2195: gcc -o conftest.out     conftest.c  >&5
configure:2198: $? = 0
configure:2221: result: .out
configure:2227: checking for suffix of object files
configure:2245: gcc -c   conftest.c >&5
configure:2248: $? = 0   
configure:2267: result: o

=> wrong EXEEXT

* i686-pc-linux-gnu -> sparc-rtems (gcc-3.2 w/ a.out):

configure:2379: checking for C compiler default output
configure:2382: sparc-rtems-gcc    conftest.c  >&5
/opt/rtems/lib/gcc-lib/sparc-rtems/3.2/../../../../sparc-rtems/bin/ld:
warning: cannot find entry symbol _start; defaulting to 00010074
configure:2385: $? = 0
configure:2430: result: a.out
configure:2435: checking whether the C compiler works
configure:2459: result: yes
configure:2466: checking whether we are cross compiling
configure:2468: result: yes
configure:2471: checking for suffix of executables
configure:2473: sparc-rtems-gcc -o conftest.out    conftest.c  >&5
/opt/rtems/lib/gcc-lib/sparc-rtems/3.2/../../../../sparc-rtems/bin/ld:
warning: cannot find entry symbol _start; defaulting to 00010074
configure:2476: $? = 0
configure:2499: result: .out
configure:2505: checking for suffix of object files
configure:2523: sparc-rtems-gcc -c   conftest.c >&5
configure:2526: $? = 0   
configure:2545: result: o

=> wrong EXEEXT

* i686-pc-linux-gnu -> i960-rtems (gcc-3.2 w/ b.out)

configure:2379: checking for C compiler default output
configure:2382: i960-rtems-gcc    conftest.c  >&5
configure:2385: $? = 0
configure:2430: result: b.out
configure:2435: checking whether the C compiler works
configure:2459: result: yes
configure:2466: checking whether we are cross compiling
configure:2468: result: yes
configure:2471: checking for suffix of executables
configure:2473: i960-rtems-gcc -o conftest.out    conftest.c  >&5
configure:2476: $? = 0
configure:2499: result: .out
configure:2505: checking for suffix of object files
configure:2523: i960-rtems-gcc -c   conftest.c >&5
configure:2526: $? = 0   
configure:2545: result: o

=> wrong EXEEXT


* i686-pc-linux-gnu -> i386-cygwin (gcc-2.95.2 w/ a.out and .exe)

configure:2101: checking for C compiler default output
configure:2104: i386-cygwin-gcc    conftest.c  >&5
configure:2107: $? = 0
configure:2152: result: a.exe
configure:2157: checking whether the C compiler works
configure:2181: result: yes
configure:2188: checking whether we are cross compiling
configure:2190: result: yes
configure:2193: checking for suffix of executables
configure:2195: i386-cygwin-gcc -o conftest.exe    conftest.c  >&5
configure:2198: $? = 0
configure:2221: result: .exe
configure:2227: checking for suffix of object files
configure:2245: i386-cygwin-gcc -c   conftest.c >&5
configure:2248: $? = 0
configure:2267: result: o
configure:2271: checking whether we are using the GNU C compiler
configure:2292: i386-cygwin-gcc -c   conftest.c >&5
configure:2295: $? = 0
configure:2298: test -s conftest.o
configure:2301: $? = 0
configure:2313: result: yes

=> Correct OBJEXT=o, correct EXEEXT=.exe, correct a.exe.

[OBJEXT=p is correct in this case; this version of i386-cygwin-gcc
produces *.o and *.exe]

Ralf






reply via email to

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