[C++-sig] bjam <dll-path> broken for installing python extensions

Avi Bahra avibahra at googlemail.com
Mon Jul 4 10:48:21 CEST 2011


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

>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
	  <install-type>PYTHON_EXTENSION
	  <install-type>SHARED_LIB
	  <dll-path>$(PYTHON_INSTALL_DIR)
	  <location>$(PYTHON_INSTALL_DIR)

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,
Ta,
    Avi


More information about the Cplusplus-sig mailing list