After https://github.com/python/cpython/pull/12946, there exists an issue on MacOS due to the two-level namespace for symbol resolution. If a C extension links against libpython.dylib, all symbols dependencies from the Python C API will be bound to libpython. When the C extension is loaded into a process launched by running the `python` binary, there will be two active copies of the python runtime. This can lead to crashes if objects from one runtime are used by the other.

https://developer.apple.com/library/archive/documentation/Porting/Conceptual/PortingUnix/compiling/compiling.html#//apple_ref/doc/uid/TP40002850-BCIHJBBF

See issue/test case here: https://github.com/PDAL/python/pull/76

Does this affect unix-style builds with --enable-shared or framework builds?

For the latter the python executable is linked to the framework, and lib python.dylib is an alias for the framework. 


A related known problem is that linking an extension to a different interpreter than it was loaded into. That is, link to /opt/lib/libpython.dylib, and use with a framework build (of v.v.).  That's one reason why linking extensions to libpython is not commonly done.

It might be interesting to experiment with "-bundle_loader ..." in the link flags instead of linking to libpython, this checks symbols not found in one of the linked to libraries against the bundle_loader ("like it was one of the dynamic libraries the bundle was linked with").  I don't know if this is a recursive check that will also look at libraries linked to by the bundle loader.

> Does this affect unix-style builds with --enable-shared or framework builds?

I believe the answer is no, since in both those cases the `python` executable doesn't contain definitions for any of the libpython symbols. In my testing I was using a python binary from anaconda, where the `python` executable defines all the symbols found in libpython.

Stop adding me to this issue.

Sorry, somehow bpo decided I added two people to this issue?  Weird.  Anyway I have removed them (Ned and "froody").

I've removed two spammy comments and adjusted the categories (the latter explains Larry's annoyance, someone selected all categories which automatically added him to the nosy list).

Linking extensions to libpython with a static build of python will cause problems (as you described in your initial message).

The not very satisfactory response is "don't do that then".  Note that distutils won't link against libpython by default.

Longer term I want to look into "-bundle_loader ..." because that might allow us to drop "-undefined dynamic_lookup" from the linker flags and hence give a nicer development experience (build-time error instead of runtime error when symbols cannot be found).

Distutils is now deprecated (see PEP 632) and all tagged issues are being closed. From now until removal, only release blocking issues will be considered for distutils.

If this issue does not relate to distutils, please remove the component and reopen it. If you believe it still requires a fix, most likely the issue should be re-reported at https://github.com/pypa/setuptools

Steve Dower: this issue is independent of distutils, reopening