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

Rene Rivera grafik.list at redshift-software.com
Thu Mar 11 16:32:23 CET 2004


Holger Joukl wrote:
>>Dave wrote:
>>I'm afraid I don't know.  I've never heard of the "-R" option before;
>>Boost.Build uses LD_LIBRARY_PATH to prepare the search path for the
>>runtime linker.
> 
> 
> Wouldn?t that mean you always have to set the LD_LIBRARY_PATH when
> importing
> an extension module that e.g. wraps a 3rd party library that is not
> installed
> in /usr/lib?

Don't think so, as Python uses different search path for dynamically loading 
modules.

> Same thing for libboost_python.so, must be in a standard place or it?s
> LD_LIBRARY_PATH again.

Yes to that. But this is something that installers (like RPM) do for you by 
running ldconfig, or equivalent.

> I created such an extension module with bjam:
> When I elfdump or ldd the resulting shared object, there is no information
> about
> where to find the libraries it depends on (including libboost_python.so).

Correct, and that's likely the optimal design as it makes the modules 
transportable. Which means you can install them to your preferred location 
instead of whatever the location you decided upon when they got built.

> Can I maybe pass the "-R ..." information as <cxxflags>?

You can use "<linkflags>", but be warned this is platform and linker specific. 
For example you call the -R flag but for the GNU linker it really should be 
the -rpath flag, and you must pass it to the linker with "-Wl,-rpath,<path>".

-- 
-- 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