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.
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-requ...@python.org wrote:
From: David Warde-Farley <d...@cs.toronto.edu>
Date: 14 September 2009 9:48:02 AM
To: Pythonmac-Sig 3 <pythonmac-sig@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
_______________________________________________
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
