Fixing Leopard's .dylib Problem With Universal MacPorts

Apparently, Mac OS X Leopard has drastically altered the way its linker works. The Ruby community is running into problems installing gems, but this change extends beyond interpreted language modules, and some people are getting really irate. I ran into this stuff head-first today while trying to make a program building off of XNJB.

I'm building an Automator action deriving from XNJB, but for the life of me I couldn't finish compiling; the linker insisted that libiconv was not defining the proper symbols. Despite libiconv being in both the OS X 10.4u and 10.5 SDKs, as well as MacPorts, the program just would not link.

If you tell Xcode to only compile for your architecture, things work out alright. But what if you want to distribute your app? Isn't that what Universal Binaries are all about? Well, apparently, the real problem with Leopard is some complicated gcc/linker mojo (something about the way Leopard resolves .dylib locations), but it's easy enough to workaround if you link to MacPorts versions of your libraries; just recompile your ports as Universal Binaries. For me, I had to recompile several:

sudo port deactivate libiconv zlib libxml2 libxslt jpeg tiff libpng

sudo install libiconv zlib libxml2 libxslt jpeg tiff libpng +universal

Ugh, MacPorts needs some common nomenclature. (Yes, I know most of that isn't their fault.) Once those were installed, and Xcode was instructed to look in /opt/local/lib for libraries, everything compiled (to a UB!) just fine. If you've got this problem, hopefully this helps!

Maybe I can use this to finish that OS X build of Panda3D.....