Re: Linking libboost_python.so to libpython

From: Dimitri John Ledkov (xnox_at_[hidden])
Date: 2020-04-03 16:28:57

Strong objection from me.

No python extensions nor applications that embed a python interpreter
should link with libpythonX.Y. The modules are effectively plugins,
and are compiled to be dlopened by the interpret and interpreter is
the one that must provide the symbols.

How an interpreter has been loaded, can be different from how an
application/extenion is linked, and thus symbols can be different.
Duplicate symbols are not a problem from ELF when they are the same,
it can become a problem when they are conflicting yet compatible. And
at that point modules can fail to load. The current schema allows
sharing compiled extensions across different builds of the python
interpret that may be shipped by different vendors.

Neither Ubuntu nor Debian links libpythonX.Y for any extension
modules, or apps. Please continue not linking against libpythonX.Y and
keep the binaries with unresolved python symbols.

For example, _ssl.so compiled extensions shipped by the python itself
has all the Py* symbols undefined, and is not linked against
libpythonX.Y.

Boost upstream, should follow Python upstream and do what they
recommend, which is not linking with libpythonX.Y.

On Fri, 3 Apr 2020 at 16:43, Jonathan Wakely via Boost
<boost_at_[hidden]> 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?
>
> In Fedora's Boost RPM packages we *do* link libboost_python.so to the
> system libpython (and we don't get any problems). 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?
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

-- 
Regards,
Dimitri.