libstdc++-v3 should not get CXX cached in <target>/config.cache

[Alexandre Oliva <oliva at lsd dot ic dot unicamp dot br>]

Since the top-level configure overhaul that started in past July,
libstdc++-v3 and libjava would have their `configure' tests run with
different views of what CXX is.

The problem was that there is a set of C++ flags, set in
CXX_FOR_TARGET, that are only known after libstdc++-v3 is configured,
so they are not passed to libstdc++-v3 in CXX.  libstdc++-v3 figures
out what the flags are, and creates a file containing them, so that
other packages that compile C++ code can use them.

Unfortunately, autoconf would cache the value of CXX passed to
libstdc++-v3, and use it in any other package that happened to have
AC_PROG_CXX in its configure.in.

This poses two different problems: one is that this second package's
configure (for example, libjava) will miss the flags that would tell
it where to find libstdc++-v3's headers.  So any C++ configure tests
are deemed to fail.  The other problem is that the multi-language
libtool, currently in use, will save the name of the C++ compiler used
at configure time and use it to tell what mechanism to use to create
shared libraries, or even to compile files so that the object files
are suitable for inclusion in shared libraries.  Because the
definition of CXX in config.cache differs from the one that is passed
to `make' to build libjava, libtool complains it can't figure out
which configuration to use and bails out.

The problem clearly lies in autoconf, right?  It shouldn't override
CXX, as passed in the environment, with that in config.cache.  But
autoconf is not to blame.  If the compiler changes, this change might
as well invalidate the whole cache.  IIRC, CVS autoconf will even warn
(or even abort) if it detects a difference between a cached compiler
name and the corresponding variable in the environment, and suggest
the user to remove config.cache and re-running configure.  It can't
just discard the cache because, when it gets to the point of testing
compilers, the cache has already been loaded.

The solution I've come up with is to arrange for libstdc++-v3, which
is the only library that needs this different notion of what CXX is,
to not get CXX cached.  This is accomplished with the following patch,
that I'm checking in as soon as my build completes.

Ben, sorry that I couldn't get to it before your vacations.  Alex,
please let me know if this, plus your changes to libstdc++.INC, help
you build libjava.  Just make sure you don't create additional
special-cases for libjava in libstdcxx_flags; instead, I suggest
adding whatever flags you need to libstdc++.INC, since any other C++
target libraries or programs are likely to need it.

Index: libstdc++-v3/acinclude.m4
===================================================================
RCS file: /cvs/gcc/egcs/libstdc++-v3/acinclude.m4,v
retrieving revision 1.82
diff -u -p -r1.82 acinclude.m4
--- libstdc++-v3/acinclude.m4 2000/11/04 03:00:08 1.82
+++ libstdc++-v3/acinclude.m4 2000/11/04 06:19:48
@@ -88,7 +88,12 @@ AC_DEFUN(LIB_AC_PROG_CXX,
 [AC_BEFORE([$0], [AC_PROG_CXXCPP])dnl
 dnl Fool anybody using AC_PROG_CXX.
 AC_PROVIDE([AC_PROG_CXX])
-AC_CHECK_PROGS(CXX, $CCC c++ g++ gcc CC cxx cc++, gcc)
+# Use CXX_libstdcxx so that we do not cause CXX to be cached with the
+# flags that come in CXX while configuring libstdc++.  They're different
+# from those used for all other target libraries.
+AC_CHECK_PROGS(CXX_libstdcxx, "$CXX" "$CCC" c++ g++ gcc CC cxx cc++, gcc)
+CXX=$CXX_libstdcxx
+AC_SUBST(CXX)
 test -z "$CXX" && AC_MSG_ERROR([no acceptable c++ found in \$PATH])
 
 AC_PROG_CXX_GNU

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me