Libtool problem with shared lib in non-standard directory
Hi, I orginally posted this http://lists.gnu.org/archive/html/bug-libtool/2006-01/msg1.html mail to the [EMAIL PROTECTED] It seems to be a bug in libtool. Hence, I will try to provide some extra information. I have a package Common that (optionally) uses the 3rd party package Boost.Threads (and log4cplus). Another package Blob depends on Common. Whenever I try to run the test (using make check) on the Blob test programs I get an error while loading shared libraries For some reason libtool does not add a -Wl,-rpath on the link line $ automake --version automake (GNU automake) 1.9.5 Written by Tom Tromey [EMAIL PROTECTED]. Copyright 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ libtool --version ltmain.sh (GNU libtool) 1.5.18 (1.1220.2.245 2005/05/16 08:55:27) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ g++ --version g++ (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5) Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. After succesfully building and installing the Common package the libtool library contains the following ... $ cat /home/loose/LOFAR/installed/gnu_debug/lib/libcommon.la # libcommon.la - a libtool library file # Generated by ltmain.sh - GNU libtool 1.5.18 (1.1220.2.245 2005/05/16 08:55:27) # # Please DO NOT delete this file! # It is necessary for linking the library. # The name that we can dlopen(3). dlname='' # Names of this library. library_names='' # The name of the static archive. old_library='libcommon.a' # Libraries that this one depends upon. dependency_libs=' -R/usr/local/log4cplus/gnu/lib -R/usr/local/boost/gnu/lib -L/usr/local/log4cplus/gnu/lib -L/usr/local/boost/gnu/lib /home/loose/LOFAR/installed/gnu_debug/lib/libshmem.la /usr/local/log4cplus102P1/gcc322/lib/liblog4cplus.la -lpthread -lrt -lboost_thread-gcc-mt' # Version information for libcommon. current=0 age=0 revision=0 # Is this an already installed library? installed=yes # Should we warn about portability when linking against -modules? shouldnotlink=no # Files to dlopen/dlpreopen dlopen='' dlpreopen='' # Directory that this library needs to be installed in: libdir='/home/loose/LOFAR/installed/gnu_debug/lib' Note that -R /usr/local/boost/gnu/lib is clearly present in the dependency_libs. Continuing to build the Blob package ... . After a successful build of this package, the libtool library contains the following ... $ cat /home/loose/LOFAR/LCS/Blob/build/gnu_debug/src/libblob.la # libblob.la - a libtool library file # Generated by ltmain.sh - GNU libtool 1.5.18 (1.1220.2.245 2005/05/16 08:55:27) # # Please DO NOT delete this file! # It is necessary for linking the library. # The name that we can dlopen(3). dlname='' # Names of this library. library_names='' # The name of the static archive. old_library='libblob.a' # Libraries that this one depends upon. dependency_libs=' -R/usr/local/log4cplus/gnu/lib -R/home/loose/LOFAR/installed/gnu_debug/lib -R/usr/local/boost/gnu/lib -L/usr/local/log4cplus/gnu/lib -L/home/loose/LOFAR/installed/gnu_debug/lib /usr/local/log4cplus/gnu/lib/liblog4cplus.la /home/loose/LOFAR/installed/gnu_debug/lib/libcommon.la -L/usr/local/boost/gnu/lib /home/loose/LOFAR/installed/gnu_debug/lib/libshmem.la /usr/local/log4cplus102P1/gcc322/lib/liblog4cplus.la -lpthread -lrt -lboost_thread-gcc-mt' # Version information for libblob. current=0 age=0 revision=0 # Is this an already installed library? installed=no # Should we warn about portability when linking against -modules? shouldnotlink=no # Files to dlopen/dlpreopen dlopen='' dlpreopen='' # Directory that this library needs to be installed in: libdir='/home/loose/LOFAR/installed/gnu_debug/lib' Again, -R/usr/local/boost/gnu/lib is present in the dependency libs. However, when trying to run any of the test programs (using make check) I get errors like: ./tKeyValueMap: error while loading shared libraries: libboost_thread-gcc-mt-1_32.so.1.32.0: cannot open shared object file: No such file or directory So, what does the link line look like. For this, I deleted tKeyValueMap and rebuild (i.e. relinked it) it by running make in the test directory. $ cd /home/loose/LOFAR/LCS/Blob/build/gnu_debug/test make tKeyValueMap /bin/sh ../libtool --tag=CXX --mode=link /usr/bin/g++ -g -W -Wall -Woverloaded-virtual -Wno-unknown-pragmas -pthread -L/usr/local/log4cplus/gnu/lib -R/usr/local/log4cplus/gnu/lib -L/home/loose/LOFAR/installed/gnu_debug/lib -R/home/loose/LOFAR/installed/gnu_debug/lib -o tKeyValueMap tKeyValueMap.o
Re: Libtool problem with shared lib in non-standard directory
Hi Marcel,
* Marcel Loose wrote on Thu, Jan 26, 2006 at 11:07:02AM CET:
I have a package Common that (optionally) uses the 3rd party package
Boost.Threads (and log4cplus). Another package Blob depends on
Common. Whenever I try to run the test (using make check) on the
Blob test programs I get an error while loading shared libraries
For some reason libtool does not add a -Wl,-rpath on the link
line
*snip*
Note that -R /usr/local/boost/gnu/lib is clearly present in the
dependency_libs.
Continuing to build the Blob package ... . After a successful build
of this package, the libtool library contains the following ...
$ cat /home/loose/LOFAR/LCS/Blob/build/gnu_debug/src/libblob.la
*snip*
Again, -R/usr/local/boost/gnu/lib is present in the dependency libs.
However, when trying to run any of the test programs (using make
check) I get errors like:
./tKeyValueMap: error while loading shared libraries:
libboost_thread-gcc-mt-1_32.so.1.32.0: cannot open shared object file: No
such file or directory
So, what does the link line look like. For this, I deleted
tKeyValueMap and rebuild (i.e. relinked it) it by running make in the
test directory.
Could you also show the link line for creating libblob.la plus libtool
output, and if it is relinked upon installation, also the same from the
relink step (that happens upon `make install' of libblob.la)? I think I
should be able to create a test to reproduce this, with that information.
As can be seen, libtool uses ../src/libblob.la on the link line. So,
if my understanding of how libtool should work is correct, then
libtool should add the -R /usr/local/boost/gnu/lib, translating this
into something -Wl, --rpath,/usr/local/boost/gnu/lib. This, however,
does not happen, as can be clearly seen from the expanded command line
above., and ldd proves that something is wrong.
This analysis seems correct to me.
Note to self: `-R' handling needs to be revisited for the indirect
deplibs issue, and your setup may be one good test case.
$ ldd tKeyValueMap
liblog4cplus.so.2 =
/usr/local/log4cplus102P1/gcc322/lib/liblog4cplus.so.2 (0x40017000)
libpthread.so.0 = /lib/tls/libpthread.so.0 (0x4007f000)
librt.so.1 = /lib/librt.so.1 (0x4008c000)
libboost_thread-gcc-mt-1_32.so.1.32.0 = not found
libstdc++.so.5 = /usr/lib/libstdc++.so.5 (0x4009f000)
libm.so.6 = /lib/tls/libm.so.6 (0x40152000)
libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x40174000)
libc.so.6 = /lib/tls/libc.so.6 (0x4200)
/lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000)
Usually, to prevent LD_LIBRARY_PATH or similar from cloaking the
picture, it is better to look at the output of all of
objdump -p tKeyValueMap
ldd tKeyValueMap
eval echo $`libtool --config | sed -n /^shlibpath_var=/{
s,,,
p
}`
(the last is portable speak for
echo $LD_LIBRARY_PATH
).
For your problem, above information is sufficient, but for my note
above, it is not.
Am I missing something here, or is this a bug???
Probable bug. I found this
http://lists.gnu.org/archive/html/libtool-patches/2003-03/msg00110.html
which may be related (but probably it's not the right place to fix
this).
Cheers,
Ralf
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: Libtool problem with shared lib in non-standard directory
* Marcel Loose wrote on Thu, Jan 26, 2006 at 11:07:02AM CET:
I have a package Common that (optionally) uses the 3rd party package
Boost.Threads (and log4cplus). Another package Blob depends on
Common. Whenever I try to run the test (using make check) on the
Blob test programs I get an error while loading shared libraries
For some reason libtool does not add a -Wl,-rpath on the link
line
Confirmed, testcase below.
Note also behavior and documentation differ in another way: for the second
library, the run-time path is actually added, cf. libtool.info:
| `-R LIBDIR'
| If OUTPUT-FILE is a program, add LIBDIR to its run-time path. If
| OUTPUT-FILE is a library, add `-RLIBDIR' to its DEPENDENCY_LIBS,
| so that, whenever the library is linked into a program, LIBDIR
| will be added to its run-time path.
Cheers,
Ralf
# 1. install a non-libtool library liba in some directory
# 2. create libtool library libb (to be installed somewhere else),
#depending on liba, with -R added suitably
# 3. create program depending on libb
: ${LIBTOOL=libtool}
: ${CC=gcc}
LDFLAGS=$LDFLAGS -no-undefined
libdir_a=`pwd`/inst_a
libdir_b=`pwd`/inst_b
rm -rf src $libdir_a $libdir_b
mkdir src $libdir_a $libdir_b
cd src
echo 'int a() { return 0; }' a.c
$LIBTOOL --mode=compile $CC $CPPFLAGS $CFLAGS -c a.c
$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o liba.la -rpath $libdir_a a.lo
$LIBTOOL --mode=install cp liba.la $libdir_a/liba.la
$LIBTOOL --mode=clean rm -f liba.la
rm -f $libdir_a/liba.la
echo 'extern int a(); int b() { return a(); }' b.c
$LIBTOOL --mode=compile $CC $CPPFLAGS $CFLAGS -c b.c
$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o libb.la -rpath $libdir_b \
b.lo -L$libdir_a -la -R$libdir_a
echo 'extern int b(); int main() { return b(); }' m.c
$CC $CPPFLAGS $CFLAGS -c m.c
$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o m m.o libb.la
./m
cd ..
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
