Boost logo

Boost :

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, 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/ (0x00007ffde6583000) => /lib64/ (0x00007fb5deefb000) => /lib64/ (0x00007fb5dec1b000)
* => /lib64/
(0x00007fb5de8cf000)* => /lib64/ (0x00007fb5de8ad000) => /lib64/ (0x00007fb5de6e4000) => /lib64/ (0x00007fb5de6ca000) => /lib64/ (0x00007fb5de6c1000) => /lib64/ (0x00007fb5de6bc000) => /lib64/ (0x00007fb5de576000)
        /lib64/ (0x00007fb5defed000)

Boost list run by bdawes at, gregod at, cpdaniel at, john at