[ python-Bugs-856401 ] Definitive way to link to the correct Python.framework

[SourceForge.net]

Bugs item #856401, was opened at 2003-12-08 20:31
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856401&group_id=5470

Category: Macintosh
Group: Feature Request
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Bob Ippolito (etrepum)
Assigned to: Jack Jansen (jackjansen)
Summary: Definitive way to link to the correct Python.framework

Initial Comment:
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.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2004-07-16 00:21

Message:
Logged In: YES 
user_id=45365

The dynamic_lookup fix has superseded this.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2003-12-09 15:49

Message:
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.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-12-09 14:11

Message:
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) $(LDFLAGS) -bundle -Wl,-
F$(PYTHONFRAMEWORKPREFIX) -framework 
$(PYTHONFRAMEWORK)

with

LDSHARED=	$(CC) $(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:-)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856401&group_id=5470