Re: Linking libboost_python.so to libpython

From: Jonathan Wakely (jwakely.boost_at_[hidden])
Date: 2020-04-03 17:07:52

On Fri, 3 Apr 2020 at 17:29, Dimitri John Ledkov <xnox_at_[hidden]> wrote:

> 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.
>

That's fine as the default, why do you object to making it configurable, so
that distros that do link python modules to libpython can do so for
Boost.Python too?

On Fedora, I see

$ ldd /usr/lib64/python3.7/lib-dynload/_ssl.cpython-37m-x86_64-linux-gnu.so
        linux-vdso.so.1 (0x00007ffde6583000)
        libssl.so.1.1 => /lib64/libssl.so.1.1 (0x00007fb5deefb000)
        libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007fb5dec1b000)
*        libpython3.7m.so.1.0 => /lib64/libpython3.7m.so.1.0
(0x00007fb5de8cf000)*
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fb5de8ad000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fb5de6e4000)
        libz.so.1 => /lib64/libz.so.1 (0x00007fb5de6ca000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007fb5de6c1000)
        libutil.so.1 => /lib64/libutil.so.1 (0x00007fb5de6bc000)
        libm.so.6 => /lib64/libm.so.6 (0x00007fb5de576000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fb5defed000)