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.