>>> from PyQt4 import QtCore
Traceback (most recent call last):
  File "", line 1, in 
ImportError: dlopen(/Library/Python/2.6/site-packages/PyQt4/QtCore.so, 2): Symbol not found: _sipQtConnect
  Referenced from: /Library/Python/2.6/site-packages/PyQt4/QtCore.so
  Expected in: flat namespace
 in /Library/Python/2.6/site-packages/PyQt4/QtCore.so

Some quick searching led me to this post, which implied that hacking PyQt’s configure.py file to force the architecture to be 64-bit would do the trick.
So where it says:

for a in sipcfg.arch.split():
    if a == 'i386':
        qmake_archs.append('x86_64')
    elif a == 'x86_64':
        qmake_archs.append('x86_64')
    elif a == 'ppc':
qmake_archs.append('ppc')

Replace qmake_archs.append('x86') with qmake_archs.append('x86_64').
Now PyQt works again.

The QTransform docs tell us that a rotation is measured in the clockwise direction. Rotation by an angle ? is computed for a given point using the matrix:

How to recover the angular rotation from this matrix? One way is to apply the same matrix to a point at x=0, y=1 and use some simple trig to figure out the angle between its original and new positions.

Enter the excellent atan2 function. Written in python, the math looks like this:

rotation = 180./math.pi * math.atan2(-xform.m21(), xform.m11())

Where xform is our QTransform object (the transformation matrix).

I wrote a little program, “Xformer,” in PyQt that demonstrates the relationship between an object’s QTransform matrix and its corresponding transformation, rotation, scale, and shear values.

Download Xformer and try it out. It requires a working copy of PyQt4.

On Linux the solution would be to add a -Wl -rpath /usr/local/qwt-5.0.2/lib to my LIBS directive in my projects’s .pro file (in this case the relevant line is in the examples/examples.pri config file). This should add the path to qwt’s dylib to my application’s runtime search path. Unfortunately this doesn’t work in Mac OS X. As it turns out, the library itself has to know its full install path.

So far, the best webpage on this problem I’ve found so far is here. It seems that Mac OS X even comes with its own utility, install_name_tool, to manage libraries’ names if one needs to move them around.

I skipped install_name_tool and opted to simply rebuild Qwt’s dylib so that it knows its install_name. My solution was to modify the LDFLAGS directive in qwt’s src/Makefile so that

-install_name libqwt.5.dylib

Looks like this instead:

-install_name /usr/local/qwt-5.0.2/lib/libqwt.5.dylib

This is not the best solution as I had to modify my Makefile directly instead of the Qt .pro file. After another make and sudo make install to reinstall the dynamic library, oTool -L libqwt.5.dylib confirms that the library’s name contains its own full path:

> otool -L libqwt.5.dylib
libqwt.5.dylib:
/usr/local/qwt-5.0.2/lib/libqwt.5.dylib . . .

More importantly, the Qwt examples all run now and I didn’t have to modify my DYLD_LIBRARY_PATH!

The next step is to modify the .pro file or my qmake.conf so it handles all this install_name magic automatically at compile/install time, but this worked well for now…

I’ll try to post more details about its design and how it works in the coming days. For now, visit the main WordRecorder page here.

I don’t know what this is about, but through some hacking and tinkering with the Xcode file I came up with the following messy workaround:

1. Make your Xcode project using qmake -spec macx-xcode if you haven’t already.
2. Open/reload the resulting project in XCode 3. Trying to edit the project properties will yield the above error.
3. Save the Project. This step is necessary as it makes Xcode totally reformat the file making the edit we’re about to do much easier.
4. Open the project’s “project.pbxproj” file in your text editor. It lives inside the “.xcodeproject” folder so you’ll have to do a “Show Package Contents” to see it in the Finder.
5. Find the following comment (“hello_world” will be the name of your own target)

   /* Build configuration list for PBXNativeTarget "hello_world" */

6. Beneath this comment you’ll see the following list of build configurations (the actual IDs will be different):

   isa = XCConfigurationList;
   buildConfigurations = (
   2F9BD7250DBC2F9500BBEE4F /* Debug */,
   2F9BD7260DBC2F9500BBEE4F /* Release */,
   2F9BD7270DBC2F9500BBEE4F /* Default */,
   );

7. Remove the entire line containing the identifier with the name ‘Default’ and save the file. The result will look like this:

   isa = XCConfigurationList;
   buildConfigurations = (
   2F9BD7250DBC2F9500BBEE4F /* Debug */,
   2F9BD7260DBC2F9500BBEE4F /* Release */,
   );

8. Go back to Xcode. It should prompt you to reload the project from disk. Reload it. You should now be able to edit your project’s properties again. Unfortunately you will have to repeat this step whenever you rebuild your project using qmake.

I don’t know why this fix works, but it beats having to recreate our Xcode project by hand, and everything still seems to build without incident after the fix.

I’m not sure if this is Apple or Trolltech’s problem as I can’t remember if this worked in Qt 4.3.3 / Xcode 2. Xcode 3 probably isn’t officially supported by qmake yet, anyway.