bug-libtool
[Top][All Lists]
Advanced

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

Re: Libtool problem with shared lib in non-standard directory


From: Ralf Wildenhues
Subject: Re: Libtool problem with shared lib in non-standard directory
Date: Thu, 26 Jan 2006 13:56:03 +0100
User-agent: Mutt/1.5.11

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 (0x42000000)
>         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

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




reply via email to

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