2006-03-12

Another Mac OS "universal binary" success story

I don't have an Intel Mac. I'm not likely to get one in the near future, either, because I don't have any particular need for another machine right now. I also don't write software for the Mac for a living, and most of what I write in my own time is Java anyway. So despite all the admonitions from Cupertino to get ready for Intel Macs over the last year, I've paid little attention.

One of the things I work on in my spare time, Terminator, has a JNI component to it. This week a user reported that "Terminator doesn't work on Intel Macs". The distribution only had a PowerPC jnilib (the Mac term for a JNI .so). If the user had been building from source, there would have been no problem. If the user had been trying to use one of the other projects that just has a helper native executable or two, there would have been no problem: Rosetta should be able to take care of that, at some performance cost. But Rosetta can't help the JVM with a PowerPC JNI library.

Now we had someone who could test the result, three lines went in to our make rules, based on Apple's "Compiling for Multiple Architectures":

universal_binary_flags := -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386
C_AND_CXX_FLAGS.Darwin += $(universal_binary_flags)
LDFLAGS.Darwin += $(universal_binary_flags)

And that's it. We now have "universal" (a.k.a. "fat") executables and jnilibs for Intel and PowerPC. Our code had been running on 32- and 64-bit big- and little-endian hardware with various instruction sets for a long time, so we weren't expecting any porting difficulties, and didn't have any.

All the same, I'm still pretty impressed at how little work needed doing. Apple's not usually good like that. Mac OS is full of Apple-specific hoops, and they expect you to jump through them to show that you care. Sure, there are things that you have to do differently to fit in on Mac OS, but there are plenty of places where they could do more automatically so that people who're developing on other platforms wouldn't have to put so much effort into Mac arcana. And even the things that are fundamentally different (applications continuing to run when all their windows are closed, having a single screen menu bar rather than per-window menu bars) could stand some Apple-supplied assistance.

I don't know why Apple chose fat binaries from the various solutions for multi-architecture support, but it's a great choice from the point of view of developers for whom Mac OS support isn't a priority. And it works out pretty well even for those of us who do care.

[I won't mention the hassle I had to go through to get Xcode 2.2 to install properly; how bad the installer's errors were; how annoying it is that even when the installer fails with an error, you have to know that there's an option on one of its menus to ask to see the detail of the error; or that failing to install Java 1.4.2 documentation (for reasons that remain unclear) is enough to halt the installer rather than just make it skip the documentation (despite that being an optional install).]