Re: Libtool doesn't set -rpath automatically when needed?

[Ralf Wildenhues]

Hello Benoit,

* Benoit SIGOURE wrote on Fri, Nov 02, 2007 at 10:34:13PM CET:
> On GNU/Linux Debian with GCC 4.1 / Debian's libtool 1.5.22-4  
> (1.1220.2.365 2005/12/18 22:14:06), I have Boost installed under /usr/ 
> local/lib (pre-built binaries: http://www.tsunanet.net/~tsuna/ 
> boost_1_34_1-i486-linux-gcc41.tar.gz) and when I link with `- 
> lboost_thread-gcc41-mt-1_34_1 -pthread' I can't run the executable  
> without manually setting LD_LIBRARY_PATH.  Shouldn't libtool do  
> something about this?  I know that Boost doesn't come with .la files  
[...]

Libtool doesn't add run paths to installed libraries without .la files.
(How should it know that it should not only add /usr/local/lib, but also
/opt/foo/lib because that is needed as well?  OK, this question is moot
on GNU/Linux, but not on other systems.)

You can use -R/usr/local/lib to make libtool add one.

> but since /usr/local/lib isn't in sys_lib_search_path_spec, shouldn't  
> it use -rpath and friends when available/required?
> What would be the best solution to handle this issue?  Write my own  
> check to see how to set the rpath (-rpath/-Wl,-rpath/-R/etc.) and  
> check if linking against -lboost_thread* requires a -rpath or not,  
> and if it does, automagically add it to BOOST_THREADS_LDFLAGS?  That  
> sounds tedious.  And how is it going to work on, say, OSX, where  
> there is no -rpath/-R?

OS X is not so much a problem because it remembers the location of the
library that was linked against at link edit time.

> Moreover, I don't see how to do such a check  
> while preserving cross-compilation capabilities (since checking  
> whether -rpath works or not requires to run the binary somehow,  
> doesn't it?

You don't need to, AC_PROG_LIBTOOL does that for you.

> Or maybe analyzing the output of `ldd'?

AC_PROG_LIBTOOL does that for you, too, on GNU/Linux.  Query by
  eval `${LIBTOOL} --config | grep "^sys_lib_search_path_spec="`

> But it surely  isn't something standard, for instance on OSX it's
> `otool -L' and it  requires the package odcctools...).

Hmm, I don't think we do that, but what would it be good for?

Cheers,
Ralf