This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]