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
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/ 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-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
Re: [Pythonmac-SIG] Appscript and Snow Leopard and setuptools...
has hengist.p...@virgin.net wrote: On 13 Sep 2009, at 18:52, Bill Janssen wrote: Is it possible to disentangle appscript from setuptools? I just downloaded the sources to my Snow Leopard machine, did python setup.py build python setup.py install which went just fine. But then I did % python import appscript and got this big stack trace because a ~/.python-eggs subdirectory wasn't accessible. That shouldn't happen, and I'd like to remove any dependence on setuptools and eggs, if possible. You can install appscript from source using plain old distutils; the setup.py script will use setuptools if it's available and distutils if not. Though if there are problems with setuptools then I'd suggest filing bug reports on that as well. I'd like to suggest an option to use distutils even if setuptools is available. Filing bug reports on setuptools seems like a losing proposition; I'd have to understand how it works first. How about *you* file the bug reports there? You're the one using it. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Appscript and Snow Leopard and setuptools...
On 14 Sep 2009, at 16:28, Bill Janssen wrote: has hengist.p...@virgin.net wrote: You can install appscript from source using plain old distutils; the setup.py script will use setuptools if it's available and distutils if not. Though if there are problems with setuptools then I'd suggest filing bug reports on that as well. I'd like to suggest an option to use distutils even if setuptools is available. Don't know how that could be done automatically as both use the same setup.py file. If you want to do it manually, replace the first five lines in the setup.py script with this: from distutils.core import setup, Extension Filing bug reports on setuptools seems like a losing proposition; I'd have to understand how it works first. How about *you* file the bug reports there? You're the one using it. I've not had any problems using it myself. Regards, has -- Control AppleScriptable applications from Python, Ruby and ObjC: http://appscript.sourceforge.net ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Link against Python Framework
On 10 Sep, 2009, at 12:09, Georg Seifert wrote: If you want to make absolutely sure that Apple can't break you, you could bundle the version of Python.framework upon which you depend into your app. However, that's probably not necessary unless you want to use a newer version of Python than the system has (say, 3.0+, or 2.6 on Leopard). How do I specify the version to link with. The 10.5 SDK links against python 2.5 and the 10.6 SDK to 2.6. But what if I need the 10.6 SKD but want to link to python 2.5? Don't compile and link using the -framework flag, but use the 'python-config' command to get the right compiler flags for linking and compiling. The python-config command is located inside the framework (such as /System/Library/Frameworks/Python.framework/ Versions/2.5/bin/python-config). If you are using Xcode you can hardcode the output of this command into your Xcode project, you don't have to run python-config every time you compile. Ronald Regards Georg ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
