Libtool and libstdc++ from a non-default gcc

[Richard Smith]

I have recently encountered a problem using libtool (in
conjunction with automake and autoconf) to link C++ DSOs on
Linux using a compiler other than my system compiler.  I
think this is probably a bug in libtool, but perhaps I'm
expecting too much from libtool.

Libtool has been configured with CC=/opt/gcc-3.3.3/bin/g++
(and similarly for CXX) and the contents of the libtool
script suggest that this has been picked up correctly.  The
libtool command line used to link the DSO is

  /bin/sh ./libtool --mode=link /opt/gcc-3.3.3/bin/g++ -o \
    libfoo.la -rpath /usr/local/lib -no-undefined \
    foo.lo -lexpat

However, I find that libtool links libfoo.la with
libstdc++.so.6 (the system compiler's C++ library) instead
of libstdc++.so.5 (the specified compiler's C++ library).

When I use g++ to link directly, viz.,

  /opt/gcc-3.3.3/bin/g++ -o libfoo.so -rpath \
     /usr/local/lib -no-undefined .libs/foo.o -lexpat

the correct version of libstdc++ is used, and when I use
libtool, but remove -lexpat, the correct libstdc++ is also
used.  (Expat does not link against either version of
libstdc++ -- it is a pure C library.)

What appears to be happening is as follows.  Libtool sees
the -lexpat option and searches for libexpat.la (c.f. line
1993 of ltmain.sh from libtool 1.5.8).  This is found in
/usr/lib/.  This causes /usr/lib/ to be added to
$newlib_search_path (line 2725).  Slightly later, libtool
does the same searching for libstdc++.la.  However, the
search paths are searched in the order:-

  $newlib_search_path
  $lib_search_path
  $sys_lib_search_path
  $shlib_search_path

It is $sys_lib_search_path that is initialised with the
compiler's internal search path (c.f. libtool.m4, line
1115), but $newlib_search_path overrides this and causes
libtool to find /usr/lib/libstdc++.la rather than
/opt/gcc-3.3.3/lib/libstdc++.la.

When libtool sources this .la file (line 2194 of ltmain.sh),
this sets dependency_libs to a bunch of -L options for the
system libstdc++ which are passed to the compiler command
line causing the wrong version of libstdc++ to be found.

By reordering the order in which the search paths are
searched (see patch, below), I have been able to fix this
problem.  However, as I don't really understand the purpose
of the $newlib_search_path variable, I'm reluctant to say
whether this will cause other problems.

Unfortunately I've been unable to produce a small test case
for this problem.

Cheers,
Richard Smith


--- ltmain.sh.orig      2004-08-17 15:56:13.373590896 +0100
+++ ltmain.sh   2004-08-17 16:42:14.529831344 +0100
@@ -1990,7 +1990,7 @@ EOF
            continue
          fi
          name=`$echo "X$deplib" | $Xsed -e 's/^-l//'`
-         for searchdir in $newlib_search_path $lib_search_path 
$sys_lib_search_path $shlib_search_path; do
+         for searchdir in $lib_search_path $sys_lib_search_path 
$shlib_search_path $newlib_search_path; do
            for search_ext in .la $std_shrext .so .a; do
              # Search the libtool library
              lib="$searchdir/lib${name}${search_ext}"