[Pythonmac-SIG] Pythonmac-SIG Digest, Vol 77, Issue 15

Geert Dekkers geert at nznl.com
Mon Sep 14 17:05:13 CEST 2009


UPDATE: Sorry, I was wrong. Client and server are equal in this  
respect. Look:

geert-dekkerss-macbook-pro:~ geert$ file /System/Library/Frameworks/ 
Python.framework/Versions/2.5/Python
/System/Library/Frameworks/Python.framework/Versions/2.5/Python: Mach- 
O universal binary with 4 architectures
/System/Library/Frameworks/Python.framework/Versions/2.5/Python (for  
architecture ppc7400):	Mach-O dynamically linked shared library ppc
/System/Library/Frameworks/Python.framework/Versions/2.5/Python (for  
architecture ppc64):	Mach-O 64-bit dynamically linked shared library  
ppc64
/System/Library/Frameworks/Python.framework/Versions/2.5/Python (for  
architecture i386):	Mach-O dynamically linked shared library i386
/System/Library/Frameworks/Python.framework/Versions/2.5/Python (for  
architecture x86_64):	Mach-O 64-bit dynamically linked shared library  
x86_64
geert-dekkerss-macbook-pro:~ geert$ file /System/Library/Frameworks/ 
Python.framework/Versions/2.5/bin/python2.5
/System/Library/Frameworks/Python.framework/Versions/2.5/bin/ 
python2.5: Mach-O universal binary with 2 architectures
/System/Library/Frameworks/Python.framework/Versions/2.5/bin/python2.5  
(for architecture ppc7400):	Mach-O executable ppc
/System/Library/Frameworks/Python.framework/Versions/2.5/bin/python2.5  
(for architecture i386):	Mach-O executable i386
geert-dekkerss-macbook-pro:~ geert$ file /System/Library/Frameworks/ 
Python.framework/Versions/2.5/bin/python
/System/Library/Frameworks/Python.framework/Versions/2.5/bin/python:  
Mach-O universal binary with 2 architectures
/System/Library/Frameworks/Python.framework/Versions/2.5/bin/python  
(for architecture ppc7400):	Mach-O executable ppc
/System/Library/Frameworks/Python.framework/Versions/2.5/bin/python  
(for architecture i386):	Mach-O executable i386

Python -- with a capital P -- is 4 way, lowercase python 2 way. Would  
Python contain classes, called by python or python2.5???

Geert


On 14/09/2009, at 12:00 PM, pythonmac-sig-request at python.org wrote:

>
> From: David Warde-Farley <dwf at cs.toronto.edu>
> Date: 14 September 2009 9:48:02 AM
> To: Pythonmac-Sig 3 <pythonmac-sig at python.org>
> Subject: Re: [Pythonmac-SIG] django webapp using CoreGraphics  
> complains about "wrong architecture"
>
>
> On 13-Sep-09, at 10:58 AM, Geert Dekkers wrote:
>
>> The problem is of course that I need to coax PyObjC to be run by 64  
>> bit Apache. I read about the ability for PyObjC to run in 64-bit  
>> mode athttp://pyobjc.sourceforge.net/documentation/pyobjc-core/news.html 
>> . I don't know where to find out if my python is built with the  
>> required MACOSX_DEPLOYMENT_TARGET=10.5, but I would think so (as  
>> I'm running 10.5.8). (And you must realise I'm no hard-core  
>> programmer -- I learn as I go -- make heaps of mistakes doing so)
>>
>> I did try a few tricks to get pyobjc to build as full fat binary  
>> (that is -arch ppc -arch i386 -arch ppc64 -arch x86_64) but so far  
>> no joy.
>>
>> (Actually one of the results was quite discerning: an example "ld  
>> warning: in build/temp.macosx-10.5-i386-2.5/Modules/_sortandmap.o,  
>> missing required architecture ppc64 in file
>> ld warning: in build/temp.macosx-10.5-i386-2.5/Modules/ 
>> _sortandmap.o, missing required architecture x86_64 in file")
>
> Neither the Python 2.5 shipped with Leopard nor the Python 2.5 at  
> Python.org are 64-bit builds/include 64 bit support. Try running  
> 'file' on the python executable, you'll see only i386 and ppc.
>
> You'll have to build a Python framework build from source as a 4-way  
> universal (I'd recommend 2.6, as there is a script in the  
> distribution for doing this on the Mac, and it might not even be  
> possible on 2.5). Then you'll be able to build 4-way PyObjC (in  
> fact, it should build that way automatically I think).
>
>> And I'm wondering if this is at all necessary. Because -- why can  
>> Apache run PIL??? -- the .so files are also not full fat, but you  
>> can indeed do "import Image"
>>
>> dekkers-2:~ geert$ file /Library/Python/2.5/site-packages/PIL/ 
>> _imaging.so
>> /Library/Python/2.5/site-packages/PIL/_imaging.so: Mach-O universal  
>> binary with 2 architectures
>> /Library/Python/2.5/site-packages/PIL/_imaging.so (for architecture  
>> i386):	Mach-O bundle i386
>> /Library/Python/2.5/site-packages/PIL/_imaging.so (for architecture  
>> ppc7400):	Mach-O bundle ppc
>>
>> But if you do "import _imaging", Apache gives you: "Could not  
>> import ccnet.views. Error was: dlopen(/Library/Python/2.5/site- 
>> packages/PIL/_imaging.so, 2): no suitable image found. Did find: / 
>> Library/Python/2.5/site-packages/PIL/_imaging.so: no matching  
>> architecture in universal wrapper"
>
>
> My best guess (as I've never poked around in the guts of PIL) is  
> that there is a pure Python version that is slow-as-molasses and  
> then a sped up C version which is used if possible (_imaging.so).  
> PIL invoked from Apache will thus probably use the slow-as-molasses  
> version as the import of _imaging will silently fail somewhere in  
> the Python code but be caught by an exception handler.
>
> David
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20090914/5a3f33a1/attachment-0001.htm>


More information about the Pythonmac-SIG mailing list