[ python-Bugs-887242 ] "-framework Python" for building modules is bad

[SourceForge.net]

Bugs item #887242, was opened at 2004-01-29 15:40
Message generated for change (Comment added) made by etrepum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=887242&group_id=5470

Category: Macintosh
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Ippolito (etrepum)
Assigned to: Jack Jansen (jackjansen)
Summary: "-framework Python" for building modules is bad

Initial Comment:
We should use the -bundle_loader method for linking 
modules for both the framework and non-framework 
verisons of Python.

All of these "version mismatch" errors would pretty much be 
avoided if this were the case, since a 10.2 and 10.3 
MacPython 2.3 should be binary compatible.  There are other 
reasons to use -bundle_loader, such as using the same suite 
of modules for both Stackless and regular Python.  Besides, 
-bundle_loader is for building -bundles :)

It's a simple change to the configure script, and it would be 
great if this could happen before OS X 10.4.

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

>Comment By: Bob Ippolito (etrepum)
Date: 2004-04-02 03:34

Message:
Logged In: YES 
user_id=139309

minimal patch for Python 2.4 CVS configure.in (and configure) attached.

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

Comment By: Bob Ippolito (etrepum)
Date: 2004-01-29 18:21

Message:
Logged In: YES 
user_id=139309

-undefined dynamic_lookup has a localized effect, it still uses two 
level namespaces and doesn't force the whole process to go flat.  

Apple uses this flag for Perl in 10.3 (maybe other things, like 
Apache), so presumably they designed it with situations like ours 
in mind.

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

Comment By: Jack Jansen (jackjansen)
Date: 2004-01-29 18:11

Message:
Logged In: YES 
user_id=45365

Ok, I only tried -bundle_loader Python.framework, and when that 
didn't work I stopped trying.

But I have some misgivings about the -undefined dynamic_lookup: 
doesn't this open up the whole flat namespace/undefined suppress 
can of worms that we had under 10.1?

What we *really* want is to a way to tell the linker "at runtime, 
the host program must already have loaded a Python.framework, 
any Python.framework, and that is what we want to link against".


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

Comment By: Bob Ippolito (etrepum)
Date: 2004-01-29 18:05

Message:
Logged In: YES 
user_id=139309

That's not true.  -bundle_loader does not generate a mach header 
load command, it is merely so that ld can make sure that all of 
your symbols are defined at link time (it will work for an 
embedded Python, try it).

You do need -undefined dynamic_lookup though, because 
-bundle_loader doesn't respect indirect symbols.  I'm not sure it's 
possible to make Python.framework get "imported" into the 
executable so that it's possible to -bundle_loader without 
-undefined dynamic_lookup (-prebind maybe, but I doubt it).

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

Comment By: Jack Jansen (jackjansen)
Date: 2004-01-29 17:53

Message:
Logged In: YES 
user_id=45365

There's a reason why I use -framework in stead of -bundle_loader: 
you can only specify an application as bundle_loader, not 
Python.framework itself. This means you have to specify the 
Python executable, which makes it impossible to load extension 
modules (including all the standard extension modules) into an 
application embedding Python. I don't think this is acceptable.

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

Comment By: Bob Ippolito (etrepum)
Date: 2004-01-29 17:24

Message:
Logged In: YES 
user_id=139309

err, this is a 10.3+ only request, and requires use of -undefined 
dynamic_lookup as well

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

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