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.

Logged In: YES 
user_id=139309

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

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.

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).

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".

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.

Logged In: YES 
user_id=139309

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

Logged In: YES 
user_id=45365

I'm finally getting around to revisiting this bug, and I ran into another 
problem (that we've already discussed offline, but I'm adding it here for 
posterity): -undefined dynamic_lookup only works if you have 
MACOSX_DEPLOYMENT_TARGET set, and set to >= "10.2".

I'm now experimenting with the following: if you have that variable set 
during configure time it will use dynamic_lookup. Moreover, it will record 
the value of MACOSX_DEPLOYMENT_TARGET in the Makefile. Distutils will 
check that the current value of MACOSX_DEPLOYMENT_TARGET is the 
same as that during configure time, and complain if not.

I've resisted the temptation to force MACOSX_DEPLOYMENT_TARGET to 
the configure-time value in distutils, because I think we may break 
things that way. Feel free to convince me otherwise:-)

I'm only doing this for 2.4 right now, as a straight backport to 2.3 is 
useless: the Makefile is already supplied by Apple. So, any fix for 2.3.X 
will need to be a band-aid in distutils (possibly triggered by an 
environment variable?).

Logged In: YES 
user_id=45365

I checked in the mods I mentioned in my previous followup:
configure.in rev. 1.455
configure rev. 1.444
Makefile.pre.in rev. 1.143
Lib/distutils/sysconfig.py rev.1.58

Logged In: YES 
user_id=580910

This was fixed a long time ago, the fix is present in 2.4. Hence closing this as 
fixed.