This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author serge-sans-paille
Recipients barry, cstratak, doko, eric.smith, koobs, martin.panter, mdk, nascheme, pitrou, serge-sans-paille, twouters, vstinner, xdegaye, yan12125
Date 2018-10-16.12:13:57
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1539692037.3.0.788709270274.issue34814@psf.upfronthosting.co.za>
In-reply-to
Content
Not an expert of Python build, but I've been creating a few « reverse engineer challenge » where I had to ship modified version of the interpreter, so played with it a bit.

I agree consistency is nice to reason about. It looks better to me to *not* link with libpython.so directly. This is probably better as this does not make ``libpython`` an install requirement (e.g. when one wants to embed a minimal version of python)

As a short check, I ran

```
nm libpython3.so | grep ' [tT] ' | cut -d ' ' -f 3 | while read line; do nm python | grep ' [tT] ' | cut -d ' ' -f 3 | grep $line >/dev/null || { echo "bad: $line"; break; }; done
```

and everything looks fine, so all symbols should already be in the interpreter.

I've also checked whether that's an issue or not for user-defined native extensions and everything runs smoothly without the explicit dep.

So the argument would be: why adding this dep when it's not needed?
History
Date User Action Args
2018-10-16 12:13:57serge-sans-paillesetrecipients: + serge-sans-paille, twouters, barry, nascheme, doko, pitrou, vstinner, eric.smith, xdegaye, martin.panter, koobs, yan12125, mdk, cstratak
2018-10-16 12:13:57serge-sans-paillesetmessageid: <1539692037.3.0.788709270274.issue34814@psf.upfronthosting.co.za>
2018-10-16 12:13:57serge-sans-paillelinkissue34814 messages
2018-10-16 12:13:57serge-sans-paillecreate