Fix python-config: no longer links with libpython.

[rdb]

This monkey patches the python-config script so that build scripts that use it don't try to link to libpythonX.X.so, which is absent from the manylinux distribution. See #69 for more information.

This also adds python-config -> python3-config symlink to Python 3 installs, analogous to the existing python -> python3 symlink.

Closes: #85

[njsmith]

Before we merge this and forget about it, can you add a link to the bugs.python.org bug report for it?

…

On Dec 20, 2016 16:42, "rdb" ***@***.***> wrote: This monkey patches the python-config script so that build scripts that use it don't try to link to libpythonX.X.so, which is absent from the manylinux distribution. See #69 <#69> for more information. This also adds python-config -> python3-config symlink to Python 3 installs, analogous to the existing python -> python3 symlink. Closes: #85 <#85> ------------------------------ You can view, comment on, or merge this pull request online at: #87 Commit Summary - Fix python-config: no longer links with libpython. File Changes - *M* docker/build_scripts/build_utils.sh <https://github.com/pypa/manylinux/pull/87/files#diff-0> (7) Patch Links: - https://github.com/pypa/manylinux/pull/87.patch - https://github.com/pypa/manylinux/pull/87.diff — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#87>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAlOaHRGRlmfcpOuKrSKtEsoCA_b5a-4ks5rKHYCgaJpZM4LSdJg> .

[rdb]

I'm reluctant to file a bug on the Python tracker, because I'm not quite convinced that this is a good change to make to Python in general. It would break too many existing and valid use cases.

• I see the use of this approach for building universally deployable wheels, but leaving symbols undefined when linking can be considered sloppy. Projects may also link with --no-undefined for this reason. In many situations there is no harm in linking to libpython.
• Platforms may not necessarily enable the use of undefined symbols or use a flat namespace for symbol lookup by default (eg. Mac).
• A valid use case for linking to libpython is to embed the interpreter. These use cases still need a straightforward way to link to the Python library. This is also relevant when freezing Python applications.
  This argument could also apply to manylinux (since people may want to ship programs that embed the interpreter), but manylinux doesn't even have libpython, rendering that use case moot.

[njsmith]

The thing about pushing it upstream is that while it's debatable whether Python extensions should link against -lpython, right now upstream is inconsistent about it: if you build CPython with --disable-shared (like we do) then distutils will not use -lpython when building extensions, but apparently python-config does. That's a bug no matter how you look at it. We didn't invent this thing with not linking to libpython.so, it comes directly from upstream :-). I actually agree that it would make more sense for all extensions to link against libpython.so, but it turns out that a common, standard, upstream-supported configuration on Linux is to ship python without any libpython.so included, so...

(And these code paths are all totally platform specific BTW. On Windows you're forced to link against python.dll because there's no such thing as pulling a symbol out of the environment. And on Mac distutils jumps through hoops to disable the default two-level namespace and --no-undefined stuff when linking.)

[dbogdanov]

What's the status of this fix? Will there be a merge anytime soon? I've stumbled into this issue in my project.

[njsmith]

I still think we need to at least file an issue upstream before applying patches to our copy of Python's source code.

[dbogdanov]

I've created an issue on the upstream. You can expand it with more details if necessary.

[trishankatdatadog]

Closing because too old. Please reopen if still interested. Thanks!