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 _______________________________________________ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig