[Pythonmac-SIG] PackMan issues

Bob Ippolito bob at redivi.com
Sun Nov 2 22:48:20 EST 2003


Both Python installations will co-exist peacefully if and only if you  
don't mix and match extension modules between the two.  You should  
technically only be using modules compiled for 10.3 Python with 10.3  
Python, and the same guideline goes for 10.2 Python.  Many people  
(including myself, sometimes) choose to ignore this guideline for  
convenience/laziness/ignorance/etc.  It is technically possible to make  
modules work for either, but you have to really know what you're doing  
(i.e. rewrite the mach load commands with install_name_tool or the  
like), but it's better to just keep separate versions.

Note also that bundlebuilder has a theoretical (but never really  
experienced, AFAIK) bug where even --standalone bundles may not work on  
certain systems due to these sorts of issues, I will work on fixing  
this.  Theoretically, --standalone applications should have all the  
load commands to be based on @executable_path rather than  
/System/Library or /Library.  This theoretical bug can also happen when  
Python installed to ~/Library (b/c the load commands will still point  
to /Library).  It hasn't caused any problems yet, but I expect them to  
happen at some point if this isn't fixed.

There are uninstallation instructions on Jack's MacPython page:  
http://homepages.cwi.nl/~jack/macpython/uninstall.html (from main page,  
left navigation, click "MacPython on OS X" then click "Uninstall  

You are right.  The real solution is of course to recompile wxWindows  
and wxPython with Xcode's gcc and 10.3 Python.  wxWindows users will  
want this recompile for gcc 3.3 anyways, because (big surprise) the C++  
ABI changed.


On Nov 2, 2003, at 9:59 PM, Kevin Ollivier wrote:

> Thank you very much! This of course does work as you say. So all that  
> is really needed for a "Panther" build of wxPython is a rebuild of the  
> installer package that puts wxPython in /System/Library instead of  
> /Library.
> However, Jack and others, I think that there should be a note about  
> this issue, because previously having both Apple python and MacPython  
> installed wasn't a problem, and people may just assume it is still the  
> case. In my case, I didn't do a clean install of Panther, and just  
> didn't bother to remove Jack's Framework build, as I had no idea these  
> sorts of problems would result from having both Pythons installed. I  
> just thought they didn't know anything about each other. Also, the  
> link on python.org points directly to the 10.2 installer -  but  
> doesn't say not to install it for Panther. (Considering Panther is so  
> new, people are likely to think that a 10.3-only installer either  
> doesn't exist yet or is not needed.) I think it may help others if  
> there's a simple note that upgraders should remove Jack's framework,  
> and also link to a 10.3 package on Python.org (or better yet a link to  
> the MacPython download page). What do you guys think?
> I'm sending this message along to the wxPython-mac list too so that  
> they can be aware that having both Pythons on 10.3 is a problem.
> On Nov 2, 2003, at 2:20 PM, Bob Ippolito wrote:
>> On Nov 2, 2003, at 4:18 PM, Kevin Ollivier wrote:
>>> On Nov 2, 2003, at 12:11 PM, Bob Ippolito wrote:
>>>> On Nov 2, 2003, at 2:54 PM, Kevin Ollivier wrote:
>>>>>> 	2) it doesn't work w/o Jack's MacPython installed because you  
>>>>>> put #!/usr/local/bin/python in the bootstrap script
>>>>> Since wxPython is compiled with gcc 3.1, it wouldn't work without  
>>>>> MacPython anyways. ;-) I hope to have this issue resolved soon,  
>>>>> but in the meantime it needs to run from Jack's installation.
>>>> That's not true, Python extensions do not use the C++ ABI.  It  
>>>> works just fine on Panther if you use #!/usr/bin/env python.  It  
>>>> doesn't matter which compiler you used, because it's only using C  
>>>> to link the two.
>>> True, but isn't that because the Python binary in the app bundle is  
>>> linked to the Python Framework? The hashbang script just sets a few  
>>> env variables and calls Contents/MacOS/python, which is linked to  
>>> the MacPython framework build. That's why even if you use  
>>> #!/usr/bin/env python, the installed status of packages tells  
>>> whether or not the package is installed in the Framework build, not  
>>> if they are installed in /Library/Python/2.3.
>>> I don't yet know the exact reason why wxPython is failing when run  
>>> from /usr/bin/python, but it is failing. If I use /usr/bin/python on  
>>> Panther instead to build the bundlebuilder app, and then copy in the  
>>> wxPython module, it crashes on load.  I get the same result (gives a  
>>> 'bus error' message) if I copy the wxPython module into  
>>> /Library/Python/2.3 and try to use /usr/bin/pythonw to run a  
>>> wxPython script. This same wxPython module works fine with the  
>>> Framework build of Python.
>>> I could well be misunderstanding something here, and if so please  
>>> let me know, but there is something that is causing wxPython to fail  
>>> with Apple's Python build. I simply thought a recompile would be the  
>>> most likely way to resolve the issue.
>> Here's a quick overview of what happens when it's launched
>> wxPackageManager.app/Contents/MacOS/wxPackageManager is executed, it  
>> actually doesn't matter which Python version it is
>> This bootstrap script locates the python executable inside the  
>> framework, and sets up the environment appropriately to run the  
>> wxPackageManager.py file with the in-framework python executable
>> The bootstrap script then does os.execve, which replaces the current  
>> process with the found python interpreter process with the new  
>> environment.  This is necessary in order to rewrite argv[0] to trick  
>> WindowServer/Foundation/AppKit into thinking that mainBundle is  
>> indeed wxPackageManager.app
>> During the dyld phase of executing the python binary, it sees the  
>> following LC_LOAD_DYLIB or LC_PREBOUND_DYLIB commands:
>>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,  
>> current version 63.0.0)
>>         /Library/Frameworks/Python.framework/Versions/2.3/Python  
>> (compatibility version 2.3.0, current version 2.3.0)
>> /System/Library/Frameworks/CoreServices.framework/Versions/A/ 
>> CoreServices (compatibility version 1.0.0, current version 14.0.0)
>> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation  
>> (compatibility version 300.0.0, current version 462.6.0)
>> On Panther, all of these are in the expected locations, except for  
>> /Library/Frameworks/Python.framework.  This is ok, because dyld looks  
>> around.  ~/Library/Framework, /System/Library/Frameworks, etc.  It  
>> finds Python.framework version 2.3.0 at /System/Library/Frameworks,  
>> links to it, and executes properly.
>> -- On a stock Panther system, *this works* --
>> If you have *two* installations of Python, namely Jack's and Apple's,  
>> you have problems!  Instead of *NOT* finding  
>> /Library/Frameworks/Python.framework and defaulting to the expected  
>> /System/Library/Python.framework, it finds both!  For example, all of  
>> the wxWindows extensions are linked against  
>> /Library/Frameworks/Python.framework .. so if you load it from a  
>> python interpreter that links to  
>> /System/Library/Frameworks/Python.framework -- then you have TWO  
>> Pythons inside your address space.  Python *can not* do this.  There  
>> are a few solutions to this, but none of them pretty..
>> 1) Just delete Jack's
>> 2) Link everything against  
>> /System/Library/Frameworks/Python.framework -- in this case, you  
>> *must always* use /usr/bin/python if you have Panther, otherwise use  
>> /usr/local/bin/python on Jaguar.  Since it won't find  
>> /System/Library/Frameworks/Python.framework, it will always find  
>> /Library/Frameworks/Python.framework (or ~/Library/Frameworks/..).
>> 3) Provide two versions (just in the way they were linked) of every  
>> extension, at runtime determine which Python has been run (by  
>> examining the location or even better the mach-o header of  
>> sys.executable) and add only that the path that contains the modules  
>> compiled with that header to sys.path.
>> This is why not understanding mach-o and dyld will bite you in the  
>> ass.  This is why I wrote potool.  Bundlebuilder and friends really  
>> need to rewrite the load commands, especially for standalone (i.e.  
>> rewrite the included python interpreter's load command and the  
>> Python.framework ID to  
>> @executable_path/../Frameworks/Python.framework/Versions/2.3/Python  
>> and so on).

More information about the Pythonmac-SIG mailing list