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

Rene Rivera grafik.list at redshift-software.com
Fri Mar 12 10:01:20 CET 2004


Holger Joukl wrote:

> Rene wrote:
> 
>>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}'
> 
> 
> If I understand correctly, this translate to an equivalent to "gcc
> -R<$ORIGIN>" with $ORIGIN being a
> relative path -- that is, simply using -R option with relative paths.

You understand incorrectly... There is no equivalent using regular searh paths 
and relative directories. The ELF linker-loader (ld.so in Linux) replaces the 
ORIGIN link variable with the path of the object doing the loading, and adds 
it to the list of search paths.

And by the way GCC will translate your -R to -rpath when it feeds it to the 
linker.

> While being fine for executables, I suspect that this is not really
> appropriate for boost.python wrapped
> libraries, where
> - libboost_python.so would probably reside in
> $PYTHON_ROOT/lib/python2.x/site-packages

You are making an assumption about locality. Why would you place it there?

> - the wrapper library shared object would probably reside in
> $PYTHON_ROOT/lib/python2.x/site-packages

Again why?

> - the wrapped library resides anywhere on your system

Like my home directory for example ;-)

> Running python and using this extension is now dependant from where you
> invoke the interpreter;

Not from where you invoke, but from where the *.so (or exec) doing the loading 
resides.

> it will only work if the wrapped lib can be found in the relative path
> $ORIGIN.

Or if it can find it in the regular search path of the system.

> So it is either LD_LIBRARY_PATH again (not good) or adding some search
> paths with -R in
> the link step, the search paths being s.th. like site-dependant standard
> library installation directories.
> E.g. a shared filesystem named /apps/prod where I would install central
> components (like python :-)

But if you use the ORIGIN link-var you can install to 
/apps/prod/something/myapp and put plugins and libboost_python*.so in a 
plugins subdir. All you need is to add the '${ORIGIN}/plugins' -rpath.

> Anyway, thanks a lot for all the hints!

You're Welcome :-)

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




More information about the Cplusplus-sig mailing list