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

[David Abrahams]

Rene Rivera <grafik.list at redshift-software.com> writes:

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

I don't think you understood.  If the module wraps a 3rd party .so,
that must be in LD_LIBRARY_PATH.

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

Right.  Most people don't want absolute paths to libraries encoded in
their objects.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com