David Abrahams suggested to raise this issue on the
Boost.Build list.
On HP-UX/ia64, Python interpreter prior to Python 2.5
assumes, that
dynamic library file has ".sl" suffix.
On a Unix system, including HP-UX, Boost.Build -- both BBv1
and BBv2 --
creates dynamic libraries with ".so" suffix. As a
result, on an HP-UX/ia64
system with version of Python prior to 2.5, boost python
library tests
creating python extension files with ".so" suffix
fail because Python
interpreter cannot load such files. Renaming extension file
from foo.so to
foo.sl
solves this problem, but this is, obviously, not a good
solution.
In BBv1, which suffix to use was configurable: there was
SUFDLL variable
defined in allyourbase.jam depending on platform. Invoking
bjam with
-sSUFDLL=.sl would override the default ".so"
suffix.
Does a similar mechanism exist in BBv2? If not, can it be
added for the
benefit of HP-UX/ia64 customers using Python prior to 2.5?
Thanks,
Boris
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
|