Toplevel configury, multilibs, new autoconf versions

[Phil Edwards]

On Sat, Jul 26, 2003 at 04:58:55PM -0400, Phil Edwards wrote:
> > >    libstdcxx_flags='`test ! -f 
> > >$$r/$(TARGET_SUBDIR)/libstdc++-v3/scripts/testsuite_flags || $(SHELL) 
> > >$$r/$(TARGET_SUBDIR)/libstdc++-v3/scripts/testsuite_flags 
> > >--build-includes` -L$$r/$(TARGET_SUBDIR)/libstdc++-v3/src 
> > >-L$$r/$(TARGET_SUBDIR)/libstdc++-v3/src/.libs'
> > >    raw_libstdcxx_flags=' -L$$r/$(TARGET_SUBDIR)/libstdc++-v3/src 
> > >-L$$r/$(TARGET_SUBDIR)/libstdc++-v3/src/.libs'
> > >
> > >Note the -L options; these get embedded into CXX_FOR_TARGET a few lines
> > >later, which becomes CXX inside the library.
[...]
> Also, I'm having trouble understanding how this manages to work at present,
> i.e., with the "old" autotools.  The -L options are still hardcoded
> either way.

Okay, I've figured this part out, and why it's breaking.  I'm going to
need some help to make this work.

To make things clearer in this email, I'm going to pretend that the CXX
variable for a normal primary build is set to Primary.  (It's actully a long
"..../xgcc -B... -L..." string.)  So, when the primary v3 configure is run,
the toplevel does it via

    CXX=Primary $srcdir/configure --stuff

Clear?

Now, at the end of that run, config.status is generated and executed.
It source's config-ml.in, which runs through the list of multilib subdirs,
and does text substitution on the env variables.  Pretend we have one
multilib, and I'll call the CXX variable for that one Multilib:

    # config-ml.in does this
    Multilib=`echo Primary | sed 's/references-to-primary-dir/references-to-multilib-dir'`

    cd up-and-over-to-multilib-dir/libstdc++-v3
    CXX=Multilib $srcdir/configure --stuff

Where "--stuff" is everything that was passed to configure.  This list of
args is stored in config.status.  Remember that for later.

That's why hardcoding things like -L into CXX at the top level still work
for multilibs.  Still clear?


Since the days of autoconf 2.13, it has been obverved that people try to
do things like this, in general:

    $ CC=foo ./configure
    $ make
        [something breaks, requiring a reconfigure]
    $ ./configure
        [oops, CC wasn't set this time, different compilers are found
        during the tests, hilarity ensues]

To protect the users from themselves, autoconf 2.5x takes note of "precious"
variables in the environment, and remembers them.

    $ CC=foo ./configure
    $ make
        [something breaks, requiring a reconfigure]
    $ ./configure
    configure: error: you're being a dumbass!

To be both safe and helpful, the configure script actually stores those
variables into the generated config.status file -- pay attention now --
as if they had been specified on the command line.  The shell variable
which stores command-line arguments is augmented with those "precious"
environment variables.


So when a multilib run is fired off with configure generated by 2.57,
the created primary config.status source's config-ml.in, which then does
this just as before:

    Multilib=`echo Primary | sed '.....'`

    CXX=Multilib $srcdir/configure --stuff 'CXX=Primary'

When configure examines the command line and sees variable assignments,
it performs them without examining the current environment.  It does this
for safety, because it thinks the user is rerunning configure.

That sound you hear is configure wailing, "MY PRECIOUSSSSSSSS!" as it
overwrites Multilib with Primary.


I've made a couple of half-hearted attempts to defeat this from within
libstdc++'s acinclude.m4, but autoconf is too smart for me.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams