Re: [libstdc++] Un-precious the CC-related variables

[Phil Edwards <phil at jaj dot com>]

[trimming gcc-patches]


On Wed, Aug 13, 2003 at 08:22:46PM -0400, Kaveh R. Ghazi wrote:
>  > From: Alexandre Oliva <aoliva@redhat.com>
>  > On Aug 13, 2003, Phil Edwards <phil@jaj.com> wrote:
>  > 
>  > > Perhaps 'cc -n32' results in LD being set to '/usr/bin/ld -n32'?  That'd be
>  > > my initial not-really-thought-about-it guess.
>  > 
>  > If LD gets propagated through the environment to multilib's configury,
>  > that would be it.  We used to have code somewhere to prevent this, though.

In the old configury, we saved and restored LD; the comment block is
still at the top of configure.ac.  Is this what you were thinking of?
It's supposed to not be neeeded anymore with the latest automake.

(I'm told that some additional multilib-related fixes are in the current
automake CVS, so as soon as 1.7.7 is released, more of configure.ac's
kludges can be removed.)


>  > My guess: if libf77 is configured before libstdc++, it caches the
>  > right values.  If libf77 is configured after libstdc++ stores the
>  > wrong value in the cache, we lose.
> 
> You're probably right.  In a serial make, I think libstdc++ goes
> first.
[...]
> Note in particular the value of lt_cv_path_LD.

I'm beginning to wonder if libstdc++ should be sharing its cache /at all/
with the other target libraries.  It seems that most of what gets cached
isn't tested in other libs; the stuff that does get used is more harmful
than useful.

Not to say we should disable caching for v3; it's quite useful.  It's trivial
to arrange the following setup:

    config.cache                 shared amongst all libs
    libiberty/
    libAAA/
    ...
    libZZZ/
    libstdc++-v3/
       config.cache              except for here

by using the following patch at the top level.  The problem is that
this kills the libjava configure:  raw_cxx is a boolean that's true
for libstdc++-v3 and libjava, and libjava is using the older autoconf,
which does not recognize -C.  If autogen has a "test module name against
a string" conditional, instead of a simple predicate-conditional, we can
do this for only v3.

Index: Makefile.tpl
===================================================================
RCS file: /home/pme/Repositories/GCC/gcc/Makefile.tpl,v
retrieving revision 1.70
diff -c -2 -r1.70 Makefile.tpl
*** Makefile.tpl        2 Aug 2003 00:48:19 -0000       1.70
--- Makefile.tpl        16 Aug 2003 22:41:02 -0000
***************
*** 1015,1019 ****
        rm -f no-such-file || : ; \
        CONFIG_SITE=no-such-file $(SHELL) $${libsrcdir}/configure \
!         $(TARGET_CONFIGARGS) $${srcdiroption} \
          --with-target-subdir="$(TARGET_SUBDIR)" \
          || exit 1
--- 1015,1022 ----
        rm -f no-such-file || : ; \
        CONFIG_SITE=no-such-file $(SHELL) $${libsrcdir}/configure \
!         $(TARGET_CONFIGARGS) $${srcdiroption} \[+
! IF raw_cxx +]
!         -C \[+
! ENDIF raw_cxx +]
          --with-target-subdir="$(TARGET_SUBDIR)" \
          || exit 1