[BTW I apologise for not updating the subject. My questions are in the bigger picture context of Python on Mac, not the need for PantherPythonFix]
You quoted something about link-time linker support for frameworks and then talk about runtime linker support..
On other platforms they are related. On Windows the contents of a .lib file at link time determines what .dll is linked to at runtime. On Linux/ ELF, rpath information (if used) is embedded at link time and affects runtime.
If you have Python 2.X and Python 2.Y both installed, as frameworks,
But earlier messages said that only Apple does the frameworks, and they don't even bother updating the one they did install let alone install other concurrent versions.
... (10.2 compatible) ...
From this statement and various others it would appear that there
were significant changes in the underlying mechanisms for deploying Python between 10.2 and 10.3. I am quite happy to ignore the existence of 10.2 :-)
Things aren't done differently..
Frameworks don't exist on the other platforms, nor did changing symbol resolution, the Mach-O format, just putting all Python stuff in /usr/lib/python-version or c:\python-version. There are many similarities, but it is different. (If it wasn't I wouldn't be asking all these questions :-)
Having extensions that can migrate between Python interpreters installed in different locations (such as inside of an application bundle) is definitely a goal, and was achieved with "-undefined dynamic_lookup" -- but is incompatible with Mac OS X 10.2 and earlier -- so both behaviors have to be supported.
Ok, that all makes sense now.
py2app of course prefers relocatable extensions, but it can solve the issue the hard way by rewriting the extension's Mach-O load commands to relocate it at build time, but there are some edge cases where it won't work (if there isn't enough room in the header to accommodate the new load commands, which has a very, very, very low chance of occurring -- I have never seen it nor heard any reports of it).
I have to do something similar with wxPython on Linux. It uses rpath to hard code the location of the wxgtk libraries in the C interface modules. That means things just work for users without having to set their LD_LIBRARY_PATH. However it is really bad news for distributing binary apps. I use a program named chrpath to strip out the rpath's. The cx-Freeze initialisation code modifies the LD_LIBRARY_PATH to point to the applications directory first, and so everything works.
What's hard to understand about "Install this fix if you use Python at all on Mac OS X 10.3"? If you don't do it, you will probably run across a problem eventually.
The PantherPythonFix is obvious. The other cases are more interesting,
especially once OS X 10.4 comes out. At that point I will want to build
on 10.3 using a Python 2.3 interpretter and extensions, and include that interpretter and extensions in the app bundle so that 10.4 users
will use the exact same Python as everyone else.
Since you won't make py2app redistribute the system Python, it means I have to use some other one and then deal with PATH and whatever else so that the correct one is picked up by default.
And then when we start using Python 2.4, OS X 10.3 will probably still be the base OS so more interesting version issues will arise.
This is *not* a Mac-ism.
It is certainly a Mac-ism that the system Python is not redistributable :-)
Roger _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
