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

[Edward Hartley]

On 14 Sep 2009, at 16:05, pythonmac-sig-request at python.org wrote:

> Send Pythonmac-SIG mailing list submissions to
> 	pythonmac-sig at python.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://mail.python.org/mailman/listinfo/pythonmac-sig
> or, via email, send a message with subject or body 'help' to
> 	pythonmac-sig-request at python.org
>
> You can reach the person managing the list at
> 	pythonmac-sig-owner at python.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Pythonmac-SIG digest..."
> Today's Topics:
>
>   1. Re: Pythonmac-SIG Digest, Vol 77, Issue 15 (Geert Dekkers)
>   2. Re: Pythonmac-SIG Digest, Vol 77, Issue 15 (Geert Dekkers)
>
> From: Geert Dekkers <geert at nznl.com>
> Date: 14 September 2009 15:44:06 BST
> To: pythonmac-sig at python.org
> Subject: Re: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 77, Issue 15
>
>
> Thanks David. As you suggested, I did a "file" on a python  
> executable, and found that while you are quite correct that python  
> is compiled a 2 way binary on a client 10.5, it's already a 4 way  
> binary on the new xserve I have running 10.5  even though it's  
> version 2.5. I also discovered that pyobjc will not automatically  
> build as a 4 way bin against a 4 way build of python, and if you  
> force it to, (by re-issuing a gcc command adding arch flags for 64  
> bit ppc and intel) it will complain about a missing architecture in  
> *.o file.
>
Mostly and I'm working from memory here to make PIL work effectively  
on 2.0 Python forward you need both numeric and IIRC ImageMagick and  
Jpeglib.
This has gone through several transitions s since I was actively using  
it.
It is worth installing and works very well particularly since you can  
get the PIL image in and out of numeric nicely.
Again from memory you need the third party jpeglib and not the OS X  
installed  one.
HTH
Ed Hartley

> I'll try doing a python 2.6 build next, and go from there.
>
> 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:
>
>
> 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.
>
> type="cite">(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? ?? -- th 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 fo und. Did 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
>
>
>
>
>
> From: Geert Dekkers <geert at nznl.com>
> Date: 14 September 2009 16:05:13 BST
> To: pythonmac-sig at python.org
> Subject: Re: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 77, Issue 15
>
>
> 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/ 
> Pyth on.frame hon
> /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 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 nning 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 t o 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
>>> /Libr ary/Pyth _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/20090919/b7c31cf9/attachment-0001.htm>