autoconf 2.57 & setting of CC
Richard Sandiford
rsandifo@redhat.com
Sun Aug 10 15:31:00 GMT 2003
I'm losing track of where we are with the autoconf vs. multilib
thing so sorry if this is old news.
A mips-sgi-irix6.5 bootstrap fails to build libE77 with:
<xgcc> <flags> .... -o .libs/libg2c.so.1.0
ld32: FATAL 12 : Expecting n32 objects: libE77/.libs/Labort.o is n64.
collect2: ld returned 4 exit status
make[5]: *** [libg2c.la] Error 1
make[5]: Leaving directory `.../mips-sgi-irix6.5/mabi=64/libf2c'
because the -mabi=64 multilib is being compiled without -mabi=64.
As far as I can tell, this is indirect fallout from the libstdc++-v3
autoconf transition. The sequence of events seems to be:
- libstdc++-v3 is the first library to be configured
- The top-level makefile invokes the configure script with:
CC="<xgcc> <flags>" ... libstdc++-v3/configure ...
- The configure script invokes config-ml.in with:
ac_configure_args="... 'CC=<xgcc> <flags>' ..."
- config-ml.in invokes configure with:
CC="<xgcc> <flags> -mabi=64" ... libstdc++-v3/configure \
... 'CC=<xgcc> <flags>' ...
- configure overwrites CC with the definition passed on the command line
(i.e. '<xgcc> <flags>')
- This definition of CC then gets assigned to ac_prog_CC and saved in
config.cache (which didn't exist beforehand, since this is the first
library to be configured).
- libf2c inherits this definition of ac_prog_CC, ignoring the
environment's value of CC.
It isn't a problem when building embedded targets in a unified tree
since newlib then gets configured first.
Richard
More information about the Libstdc++
mailing list