New tools and multilibs fight with one another

[Phil Edwards]

But it's a very subtle fight.  Goes like this:

Autoconf 2 has always taken note of env variables like CC.  This is the
norm for target libraries, since nearly all of their compiler-related
settings are passed in the environment during the initial configure.
Autoconf 2.5x now remembers which settings come from the environment,
and what their values are.  And when it needs to reconfigure, it re-passes
those arguments on the configure command line.

So, when a target library's configure "source"s the toplevel config-ml.in,
and config-ml.in looks at the command-line args, all the env variables
passed down from the toplevel are also visible in the argument list.

Somewhere, some quoting gets lost.

For libstdc++-v3, one of the env options is

    'CXX= ...... -nostdinc++ ....'

config-ml.in loops over each one of the words in CXX, and does the little
"if they only typed one leading dash, make it two" helper bits, so it's
"as if"

    'CXX= ...... --nostdinc++ ....'

Then, it tries to interpret each of the options in a manner best described
as greedy:

      case $option in
        --*) ;;
        -*) option=-$option ;;
      esac

      [....]

      case $option in
      [....]
        --norecursion | --no*)
            ml_norecursion=yes
            ;;

Using printf-style debugging, I've verified that it sees -nostdinc++,
and thinks it's seen --norecursion.  And with ml_norecursion set, the
entire loop (later in the script) which creates the multilibs directory
structure in the build tree is skipped.

All of the target libraries Makefiles then have code which looks like

    if test -d $the_multilib_dir; then
        cd there && do everything
    else true; fi

As a result, libstdc++ silently fails to build any multilibs.  Only the
primary library tree is built.  And I suspect that any target library
which uses a -no* flag passed down from the toplevel configure would see
the same misbehavior if the new autoconf were applied.  Looking at toplevel
configure.in, I think that means only libjava at present.


Two possible simple fixes, both in config-ml.in:

1)  Kill that "add a leading dash" bit.

2)  Stop assuming that anything beginning with --no must be --no-recursion.
    (We can insert the - in the middle of the word while we're at it.)

Other fixes are not so simple.  Clearly config-ml.in should not be looking
"inside" env variables, but I don't know how to change that.


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