On 14 Sep 2009, at 16:05, pythonmac-sig-requ...@python.org wrote:
Send Pythonmac-SIG mailing list submissions to
pythonmac-sig@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-requ...@python.org
You can reach the person managing the list at
pythonmac-sig-ow...@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 <ge...@nznl.com>
Date: 14 September 2009 15:44:06 BST
To: pythonmac-sig@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-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:
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 <ge...@nznl.com>
Date: 14 September 2009 16:05:13 BST
To: pythonmac-sig@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-requ...@python.org wrote:
From: David Warde-Farley <d...@cs.toronto.edu>
Date: 14 September 2009 9:48:02 AM
To: 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 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
_______________________________________________
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
