Insyteful

I've moved away from using the Python from MacPorts (DarwinPorts) and am, instead, using the Official Mac Python build from python.org. Overall, it seems to have been a good move. However, the first time I tried to build a C module using distutils, ld popped up this error when trying to link against libcrypto.dylib:

cputype (18, architecture ppc) does not match cputype (7) for specified -arch flag: i386 (file not loaded)

Scrolling back to look at the actual gcc command line revealed a clue. Present among the flags were: -arch i386 -arch ppc.

Another clue:

tarja:~ ben$ file /opt/local/lib/libcrypto.0.9.8.dylib /opt/local/lib/libcrypto.0.9.8.dylib: Mach-O dynamically linked shared library ppc

So Python's distutils was determined to build universal binaries, but the OpenSSL install created by MacPorts was PPC only. That's not going to work.

A grep through the source for distutils didn't reveal any instances of "-arch i386", so I resorted to Google. This post provided the necessary clue. After editing /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/config/Makefile and removing all references to -arch i386, the linking succeeded.

Almost.

Then I started seeing errors similar to this one: /usr/bin/ld: warning can't open dynamic library: /Developer/SDKs/MacOSX10.4u.sdk/opt/local/lib/lib3rdparty.dylib referenced from: libMyLibrary.dylib (checking for undefined symbols may be affected) (No such file or directory, errno = 2)

Note that in this example, lib3rdparty.dylib actually does exist in /opt/local/lib. As I eventually learned from this thread, using the -isysroot option prepends the SDK directory to all paths. As you'll note from the above-linked thread, whether or not this is a bug depends on who you ask. The kludgy workaround:

Make a symlink under /Developer/SDKs/MacOSX10.4u.sdk/ to /opt/local/lib.

Ugly.

But it works.

Thanks, Apple.