[Pythonmac-SIG] django webapp using CoreGraphics complains about "wrong architecture"

[David Warde-Farley]

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