Hi Jonathan, On 2020-04-03 11:43 a.m., Jonathan Wakely via Boost wrote:
tools/build/src/tools/python.jam says:
# On *nix, we do not want to link either Boost.Python or Python extensions # to libpython, because the Python interpreter itself provides all those # symbols. If we linked to libpython, we would get duplicate symbols. So # declare two targets -- one for building extensions and another for # embedding.
Why would that give duplicate symbols? Wouldn't ELF symbol interposition mean that only one is used? Why would it be a problem to link to libpython?
Do all *nix variants use ELF these days ?
In Fedora's Boost RPM packages we *do* link libboost_python.so to the system libpython (and we don't get any problems).
What is your rationale for this, given that (according to the above reasoning) symbols will be resolved from the application that's loading the module ?
But to do this, we have these two local patches:
https://src.fedoraproject.org/rpms/boost/blob/master/f/boost-1.57.0-python-l...
and then to make it link to libpython3.7m.so (rather than libpython3.7.so) we have this patch to pass the "m" into the Boost build:
https://src.fedoraproject.org/rpms/boost/blob/master/f/boost-1.66.0-python-a...
I'd prefer not to need these local hacks. Would the upstream Boost.Python consider making changes so that libboost_python.so can be (optionally) linked to libpython?
Is there a cleaner way to do this than those patches?
I fully agree that whatever seems the right choice of build (including link) process for a given platform, we (boost) should incorporate that into our own infrastructure, so downstream package maintainers don't need to patch it. I'll leave it to the Boost.Build maintainers to answer the technical details of that process. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...