[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Libtool and libstdc++ from a non-default gcc

From: Richard Smith
Subject: Libtool and libstdc++ from a non-default gcc
Date: Tue, 17 Aug 2004 17:33:35 +0100 (BST)

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 \ -rpath /usr/local/lib -no-undefined \
    foo.lo -lexpat

However, I find that libtool links with (the system compiler's C++ library) instead
of (the specified compiler's C++ library).

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

  /opt/gcc-3.3.3/bin/g++ -o -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 (c.f. line
1993 of 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  However, the
search paths are searched in the order:-


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/ rather than

When libtool sources this .la file (line 2194 of,
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.

Richard Smith

---      2004-08-17 15:56:13.373590896 +0100
+++   2004-08-17 16:42:14.529831344 +0100
@@ -1990,7 +1990,7 @@ EOF
          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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]