This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
autoconf 2.57 & setting of CC
- From: Richard Sandiford <rsandifo at redhat dot com>
- To: gcc at gcc dot gnu dot org
- Cc: libstdc++ at gcc dot gnu dot org, phil at jaj dot com
- Date: 10 Aug 2003 16:26:59 +0100
- Subject: autoconf 2.57 & setting of CC
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