[PyQt] PyQt on OSX Snow Leopard notes
phil at riverbankcomputing.com
Sun Sep 13 12:12:35 BST 2009
On Fri, 11 Sep 2009 10:00:39 -0500, William Kyngesburye
<woklist at kyngchaos.com> wrote:
> On Sep 11, 2009, at 8:57 AM, Phil Thompson wrote:
>> On Fri, 4 Sep 2009 09:13:08 -0500, William Kyngesburye
>> <woklist at kyngchaos.com> wrote:
>>> For those trying this, here's what I found so far:
>>> - gcc compiles 64bit by default now, which will cause problems with
>>> the 32bit-only Qt (unless you are using Qt Cocoa). Configure SIP
>>> universal so you get a 32bit SIP (the extra PPC code is harmless,
>>> except that PyQt will take longer to compile and be larger than
>>> necessary). If you want 32bit-only or 32+64bit intel, you need to
>>> edit siputils.py and change the unicflags and unilflags lines
>>> - the macx-g++ Qt mkspec is meant to run the current gcc version,
>>> which is now 4.2. But there is also a specifically macx-g++42
>>> mkspec. I figured macx-g++ should agree more with Qt, which was
>>> with gcc 4.0, so I edited it to run 4.0. I don't know if it's really
>>> a problem anywhere down the line. Maybe there should be a macx-g++40
>>> now. But I don't know how to select a mkspec in the PyQt
>>> configuration (I haven't looked).
>>> - the python 2.6 executable is 32+64bit now, and will run 64bit by
>>> default. This is a problem with pyuic4, which is a shell script which
>>> runs a python script (with pythonw). At first I thought to use the
>>> arch command in pyuic4 shell script to run pythonw in 32bit mode, but
>>> apparently the arch command is broken and pythonw would still run
>>> 64bit. So I ended up creating a stripped copy of pythonw in /usr/
>>> local/bin with ditto:
>>> sudo ditto -arch i386 /usr/bin/pythonw2.6 /usr/local/bin/pythonw32
>>> and running that from the pyuic4 script. If any of your PyQt-based
>>> applications run from python, they'll have to use this also. Unless,
>>> of course, you use Qt Cocoa and compile PyQt 64bits.
>> Using Python v2.6.2 from python.org, and after recompiling Qt, then
>> builds as normal.
> Because it's 32bit only.
>> Until Qt properly supports Snow Leopard I think I'll leave things as
> It's not so much a problem of Qt supporting Snow (yes, the mkspec
> problem, but it seems to be minor), but supporting OSX 64bit, which
> covers both Leopard AND Snow. The standard Carbon-based Mac Qt will
> never be 64bit. Qt Cocoa is 64bit (I have yet to try it out).
> And there is now the extra 64bit-ness of Python in Snow now, which
> causes trouble with Python-based software. People WILL update to Snow
> and WILL (and have already) have problems compiling PyQt.
> Since Qt Cocoa may take a while to be fully functional and in common
> use, PtQt at least needs some way to deal with a 64bit Python
> executable (use the arch command where python/pythonw executed when
> built for Qt carbon).
> Note: I just figured out the problem with the arch command. It's not
> broken. There are 2 copies of the python and pythonw executables: in /
> usr/bin and in the Python framework. The /usr/bin exe's are not
> symlinks to the framework, and have different file sizes. For some
> reason the /usr/bin exe's don't work with arch, but the framework
> exe's do. /usr/bin/python2.6 and /usr/bin/pythonw2.6 ARE symlinks to
> the framework.
I've added a --arch option to SIP's configure.py. It may be specified any
number of times. PyQt's configure.py will also use the information.
I've added a --use-arch option to PyQt's configure.py to tell it to use
arch in the pyuic4 wrapper script. If there is a problem with
/usr/bin/python then you should run configure.py using /usr/bin/python2.6
The changes are in the current snapshots. Let me know if more needs to be
More information about the PyQt