Boost logo

Boost :

From: Stefan Seefeld (stefan_at_[hidden])
Date: 2020-04-03 15:53:40


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-libpython_dep.patch
>
> 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-abi_letters.patch
>
> 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...

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk