On Fri, 3 Apr 2020 at 17:29, Dimitri John Ledkov
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)