[C++-sig] Re: boost.build: How to set runtime library paths in a Jamfile (wrapping 3rd party libs)

[Rene Rivera]

Ingo Luetkebohle wrote:

> Am Do, den 11.03.2004 schrieb David Abrahams um 16:41:
> 
>>Right.  Most people don't want absolute paths to libraries encoded in
>>their objects.
> 
> 
> While that might be so, it says nothing about ld's '-R' (or '-rpath' on
> Linux) option.  That option prepends a directory to the run-time linker
> search path.  There is no absolute path to a library, the library is
> searched as usual, but in additional locations.

I'm sorry but that makes no sense to me :-( Yes you can add search locations, 
but you can't predict all the search locations that a user might want to move 
a library to. For example I prefer to install all libraries of a program with 
the program, and there is no way to predict where that is.

> Most people I know prefer that to LD_LIBRARY_PATH very much ;-)

Most people don't know about the alternatives available with ELF 
linker-loaders ;-)

> One reason is that it can be applied to a single shared object or
> executable, instead of applying unconditionally to everything.  Like,
> "for *this* library, look in '/usr/local/boost/lib' for additional
> dependencies".  

But it would not know to search.. "/home/user/boost_1_31_0/lib"

> Another pro is that it works with setuid binaries while LD_LIBRARY_PATH
> usually does not, for obvious reasons.

And for good reason... ldconfig, and other system level configuration of the 
load search path and library cache is the preferred way to manage that.

> While moving libraries is an issue, one can always re-link with a
> different RPATH.  libtool does that, for example.

You can only relink if you have a linker. So if you only distribute binaries 
you are out of luck.

I went over all these issues and more a long time ago in trying to figure out 
how to manage distribution for my current project and there are many things I 
can say about the Unix/Linux link loading model, but the nicest I can say is 
that it's broken. In the end I resorted to using the highly under documented 
feature of ELF for adding searchs paths relative to the loading module. So now 
I can get the effect I have on Windows of adding the location of my executable 
(or any other relative subdir) to the library search path...

	<gcc><*><linkflags>-Wl,-rpath,'${ORIGIN}'


-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq