[Pythonmac-SIG] PackMan issues

[Kevin Ollivier]

Hi Bob,

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.

Thanks again,

Kevin

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