Bugs item #887242, was opened at 2004-01-29 21:40 Message generated for change (Settings changed) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=887242&group_id=5470
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: Platform-specific >Status: Closed >Resolution: Fixed 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: Ronald Oussoren (ronaldoussoren) Date: 2006-06-25 23:28 Message: 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. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2004-06-03 14:42 Message: 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 ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2004-06-02 23:37 Message: 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?). ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-04-02 10: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-30 00: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-30 00: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-30 00: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 23: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 23: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 _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
