[PyQt] PyQt on OSX Snow Leopard notes

Phil Thompson phil at riverbankcomputing.com
Fri Sep 11 17:05:23 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
>>> appropriately.
>>> - 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  
>>> built
>>> 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  
>> PyQt
>> builds as normal.
> Because it's 32bit only.
>> Until Qt properly supports Snow Leopard I think I'll leave things as  
>> they
>> are.
> 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'm not convinced this is a PyQt problem - even though it affects PyQt
users. If you are on a 64 bit system then you would expect to be building
64 binaries, ie. 64 bit Qt Cocoa, not 32 Qt Carbon. I assume that when Qt
"properly" supports Snow Leopard then that would be the default on 64 bit
systems. In which case the standard build process, and pyuic, will continue
to work.

The current problems seem to be due to Qt being slow to support Snow
Leopard, or maybe just slow to make Cocoa the default. I don't think PyQt
should be expected to work around this temporary situation. I'd change my
mind if you were to say that the Cocoa support was flakey and people will
be sticking with Qt Carbon for some time to come.


More information about the PyQt mailing list