Issue 856401: Definitive way to link to the correct Python.framework (original) (raw)

Issue856401

Created on 2003-12-08 19:31 by bob.ippolito, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (4)
msg19325 - (view)	Author: Bob Ippolito (bob.ippolito) *	Date: 2003-12-08 19:31
The link target for Python should be specified by introspecting the Python framework itself and linking directly to the framework dylib, rather than using -framework and overriding the framework search path with -F. Using -F may have undesirable side-effects. Example: User has Python at /Library/Frameworks and wants to build an extension module that links to ~/Library/ Frameworks/FooFramework.framework. User also has a / Library/Frameworks/FooFramework.framework that they do not want to link against. Solution: Rather than -framework Python, Python should link directly to NSBundle.bundleWithIdentifier_('org.python.Python.framewor k').executablePath(). Stock 10.3 has this located at: u'/System/Library/Frameworks/Python.framework/Python'. The value of this is entirely dependent on the current running version of Python that the extension module will be linked against. The dylib identifier will of course be expanded to the full /System/Library/Frameworks/Python.framework/ Versions/2.3/Python by the linker. Caveats: Example requires PyObjC, however these APIs are available in CoreFoundation's CFBundle and could easily be put into an extension module if PyObjC is not to be distributed with the next version of Python. It will likely require a platform specific patch to distutils.
msg19326 - (view)	Author: Jack Jansen (jackjansen) *	Date: 2003-12-09 13:11
Logged In: YES user_id=45365 Bob, I'm not convinced. First, the problem you sketch seems a bit academic (the user linking a Python extension against a framework for which one system-wide copy and one per-user copy exists), and there is a workaround too (the user adds another -F just before their own framework). Second, I'm not convinced that "-framework Python" doesn't do more than just linking against the dylib inside the framework, or that it may do so in the future. Finally, with the current distutils we cannot easily use introspection to get the real location of the framework that python is running from: distutils picks up this value from the Makefile LDSHARED variable, so the only thing we can do without distutils surgery is replace LDSHARED= (CC)(CC) (CC)(LDFLAGS) -bundle -Wl,- F$(PYTHONFRAMEWORKPREFIX) -framework (PYTHONFRAMEWORK)withLDSHARED=(PYTHONFRAMEWORK) with LDSHARED= (PYTHONFRAMEWORK)withLDSHARED=(CC) (LDFLAGS)−bundle(LDFLAGS) -bundle (LDFLAGS)−bundle(PYTHONFRAMEWORKINSTALLDIR)/$(PYTHONFRAMEWORK) All in all I'm tempted to close this as "won't fix", but I'll give you another couple of days to convince me otherwise:-)
msg19327 - (view)	Author: Bob Ippolito (bob.ippolito) *	Date: 2003-12-09 14:49
Logged In: YES user_id=139309 1) Yeah, it's a little academic, but it solves a problem we have without changing the normal link order that a user will probably expect. -F can be wrong too, if PYTHONFRAMEWORKPREFIX is compile time. 2) Trust me, it doesn't do more than linking against the dylib inside the framework. There is nothing in the mach-o spec it *could* do, unless they add framework specific load commands in OS X 10.4+ (doubtful). I know those header files pretty well and have looked at bits and pieces of related darwin source (nm, otool, install_name_tool, etc). 3) Yeah the current distutils is a pain in the butt. I don't like the easy change to distutils. Maybe it fails for a user install version of Python if PYTHONFRAMEWORKPREFIX is set at compile time? I'd MUCH rather have this dir come from introspection because then it will be correct, for example from a 10.3 SDK on 10.4.
msg19328 - (view)	Author: Jack Jansen (jackjansen) *	Date: 2004-07-15 22:21
Logged In: YES user_id=45365 The dynamic_lookup fix has superseded this.