bjam <dll-path> broken for installing python extensions

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

bjam <dll-path> broken for installing python extensions

Avi Bahra
Using boost 1.45, on linux  suse, gcc

I am trying to install a shared library(python extension), and I want
to hard code
the path to the boost python shared library, so that my users don't need to

>From reading the bjam documentation, I should be using <dll-path>.
This works for an executable which needs to hard code  a path to
a shared library. However it does not work for a shared library that
needs to embed a hard coded path to another shared library.
(i.e boost python shared library).

install install-py
        : Pyext//ecflow
        : <install-dependencies>on

My expectation was that use of <dll-path> during a install should
force a re-link, with
and add the equivalent of -Wl,rpath. However it does nothing.

The hacky way to get around this bug appears to be use <dll-path>
when building the extension. Hacky because I want to use development
lib, and not the installed hard code path.
Even this hack does not work on other unix flavours, so you are pretty
much hosed in trying to use bjam for installation of python extensions.

It also appears that <hardcoded-dll-paths> does not apply to python
extensions. The only unix flavour where this works is HPUX.

I am sure this problem is not new,  so I'm wondering how do other
people handle installation of boost python extensions.
Is there no alternative to LD_LIBRARY_PATH ?

   Best regards,
Cplusplus-sig mailing list
[hidden email]