Libtool 1.5.18: unpredicable linking to stdc++

[Graham Leggett]

Hi all,

While attempting to build two C++ library projects A and B, on a Solaris
v2.8 environment with gcc v4.0.1 (in a private directory) and gcc v3.4.2
(in /usr/local) both installed in the path, and with gcc v4.0.1 taking
precedance, libtool pulls in either the v3.4.2 stdc++, or the v4.0.1
stdc++ at random, despite g++ v4.0.1 being used to build both projects A
and B.

Project A always pulls in v3.4.2's stdc++:

dependency_libs=' -R/usr/local/lib -R/usr/lib -R/usr/openwin/lib
-R/usr/local/BerkeleyDB.4.2/lib -R/usr/local/ssl/lib  -L/usr/local/lib
-L/usr/lib -L/usr/openwin/lib -L/usr/local/BerkeleyDB.4.2/lib
-L/usr/local/ssl/lib
-L/usr2/SOURCES/S8/gcc-3.4.2/objdir/sparc-sun-solaris2.8/libstdc++-v3/src
-L/usr2/SOURCES/S8/gcc-3.4.2/objdir/sparc-sun-solaris2.8/libstdc++-v3/src/.libs
-L/usr2/SOURCES/S8/gcc-3.4.2/objdir/gcc
-L/usr/local/sparc-sun-solaris2.8/bin
-L/usr/local/sparc-sun-solaris2.8/lib
-L/usr/local/lib/../sparc-sun-solaris2.8/lib -L/usr/ccs/bin -L/usr/ccs/lib
/usr/local/lib/libxml2.la -lpthread -lintl /usr/local/lib/libiconv.la
-lnsl -lsocket
 -lz /usr/local/lib/libstdc++.la -lgcc_s -lm -lc   '

Project B always pulls in v4.0.1's stdc++:

dependency_libs=' -L/udd001/app/sybase/product/ASE120/OCS-12_0//lib
-L/usr/openwin/lib -L/usr/X11R6/lib -L/usr/lib
-L/udd001/hoops/usr/src/objdir/sparc-sun-solaris2.8/libstdc++-v3/src
-L/udd001/hoops/usr/src/objdir/sparc-sun-solaris2.8/libstdc
++-v3/src/.libs -L/udd001/hoops/usr/src/objdir/gcc
-L/udd001/hoops/usr/sparc-sun-solaris2.8/bin
-L/udd001/hoops/usr/sparc-sun-solaris2.8/lib
-L/udd001/hoops/usr/lib/gcc/sparc-sun-solaris2.8/../../../sparc-sun-solaris2.8/lib
-L/udd001/hoops/usr/lib/gcc/sparc-sun-solaris2.8/../..
/udd001/hoops/usr/lib/gcc/sparc-sun-solaris2.8/4.0.1/../../../libstdc++.la
-lssl -lcrypto -lmqic -lsybdb -lxview -lolgx -lXm -lXt -lXext -lX11 -ldl
-lnsl -lsocket -lc
/udd001/hoops/usr/lib/gcc/sparc-sun-solaris2.8/../../libstdc++.la

Opinion on the libtool mailing list suggests that libstdc++ should not be
explicitly linked to at all, as the compiler works this out by itself.

So the bug is either:

- The libstdc++ is somehow pulled into the dependency_libs variable when
it should not be pulled in at all.

- The libstdc++ library should be pulled in by libtool, but this should
always be the libstdc++ corresponding to the compiler being used, and not
a random version of the library.

I have tried to reverse engineer ltmain.sh and libtool to find out what
method is being used to detect libstdc++, but with no luck.

This bug renders it impossible to build C++ code trees on a Solaris system
with more than one compiler installed.

Regards,
Graham
--