Well, Apple's WorldWide Developers Conference is all wrapped up.
WWDC is always a good time, and this year we had some doozy announcements.
We had very good turnout at Tommy's Mexican Restaurant on both Sunday and Wednesday nights. Julio was not present either night, but we had enough Tequila students in the house to keep everyone drinking good stuff. As such, I say WWDC was a success.
There was also an announcement about Apple moving it's computers to a new processor architecture. It shouldn't have been a huge surprise to those who have been paying attention that Mac OS X has been built from day one to be relatively processor-agnostic, and that continuing support for the the Intel processor family (*), at least at the Darwin level, has been a valuable way to ensure that it remains so. What wasn't known until Monday's keynote was that the entire OS stack has been running on Intel all along as well.
There has been some concern that this transition might be very difficult for Apple and for Apple's developers. I think not. In fact, if Apple shipped an Intel Mac today, I'd have plenty of use for it even without any third-party apps. This is because almost everything I use on my Mac (email, web, IM, text editor, etc.) comes with the OS, and much of the rest I build myself. I would have little doubt that LaunchBar and SubEthaEdit (both Cocoa apps) will be available in short order. Done! OK, I want PhotoShop and Quicken (Carbon) also, but for those, I still have my PowerMac until they are ready, which may not be much longer; I don't know much about what's involved with getting Carbon apps going.
On the open source front, which is more my area, there are actually a couple of challenges. Simply building on Intel if you have an Intel Mac will not be hard. In most cases, it will just work. The may be a couple of dumb assumptions people make about Darwin, but those aren't that hard to fix. Somewhat more challenging will be in building "fat" (know also called "universal") binaries, or cross-compiling. This involves building for Intel on a PowerPC system or vice versa. We've been using fat binaries for a while, by the way, for 64-bit software:
wsanchez% echo 'int main() {}' > /tmp/foo.c
wsanchez% cc -arch ppc -arch ppc64 /tmp/foo.c -o /tmp/foo
wsanchez% file /tmp/foo
/tmp/foo: Mach-O fat file with 2 architectures
/tmp/foo (for architecture ppc): Mach-O executable ppc
/tmp/foo (for architecture ppc64): Mach-O 64-bit executable ppc64
Here we have a fat binary for two platforms: 32-bit PowerPC and 64-bit PowerPC. You can also use fat binaries to, say, build for G4 and G5, allowing you build the G5-optimized code (using the -mcpu flag) which is incompatible with the G4, but still have a binary that runs on the G4. I don't know that you can do that in one compiler invocation, but you can build once for each then merge the binaries into a fat one using lipo. But I digress…
Where this gets tricky in open source projects, specifically with those that use autoconf and libtool, in that neither of these tools knows about multi-architecture compilation and linking. autoconf does know a bit about cross-compiling, but that functionality is rarely used. Fortunately, we don't need it. All we need for a first pass is to be able to override CFLAGS and CPPFLAGS so that we can add in -arch ppc -arch i386. This should work for every such project:
wsanchez% configure CFLAGS="-Os -arch ppc -arch i386" LDFLAGS="-arch ppc -arch i386"
wsanchez% make
…
Unfortunately, a fair number of makefiles are broken and fail to build your project if you do this. A very common problem is the placement of C preprocessor options into CFLAGS into CPPFLAGS, or the placement of some required options into CFLAGS that, when overriden, fail to compile. These are bugs in the makefiles which need fixing, as per the GNU Coding Standards Makefile Conventions, which one is generally expected to follow when using autoconf and/or automake. It is highly useful for open source projects to follow these conventions in makefiles, so maintainers will hopefully be willing to accept patches to improve conformance.
Ideally, autoconf and libtool will know how to build fat on their own. It would be great if autoconf on OS X would detect the architectures that your system can build on and build for all of them. One might want to have an option to turn that on or off (whether it should do so by default is debatable).
I lied a little bit. You may also have to add -isysroot=path_to_universal_sdk to CFLAGS as well. On the Intel developer systems, the OS has fat system libraries in it. For example, /usr/lib/libSystem.B.dylib will be fat for ppc and i386 (and ppc64, presumably). But on your PowerMac with Tiger on it, you don't have that, so you have to install the Universal SDK. This presents another problem. If you want autoconf to build fat automatically, it's going to need to be able to find the SDK. Unfortunately, I don't see an easy way to find the "right" SDK to build against without prompting the user. So it might have to be a specified option. Since -isysroot is not a Mac-specific gcc option, a --sysroot standard option to autoconf might be in order.
Another common problem is in software that tries to determine CPU-specific information at configure time. For example, a program might use autoconf to determine the endianness of the host platform and set a compiler flag accordingly. autoconf tries to provide a way around that if you are cross-compiling, but it's not the best solution in this case. What you want to do here is use the CPP macros defined by the compiler for you, such as:
- __POWERPC__
- __INT_MAX__
- __LONG_LONG_MAX__
- __BIG_ENDIAN__
- __NATURAL_ALIGNMENT__
To get a full list of these, this works:
wsanchez% echo 'int main() {}' > /tmp/foo.c
wsanchez% cc -E -dM /tmp/foo.c
#define __DBL_MIN_EXP__ (-1021)
#define __FLT_MIN__ 1.17549435e-38F
#define __CHAR_BIT__ 8
…
Another tangent: One should really avoid assiging any meaning to the __APPLE__ macro, which was probably a bad idea to define. __APPLE_CC__ means you are using an Apple compiler (and should probably only be used in combination with __GNUC__ to let you know you have Apple's gcc, specifically. Neither of these means that you are compiling for Darwin or PowerPC or that the filesystem, is case insensitive or any of the many goofy assumptions people make regarding these macros. __MACH__ is probably not useful in a healthy way either. Don't do it; it'll eventually bite you in the ass.
*: Note that OpenStep, from which Mac OS X's core draws much of it's heritage, ran on the Motorola 68040, HP PA-RISC, Intel x86, DEC Alpha, and Sun SPARC processors. It had also been ported to PowerPC, though NeXT killed off hardware operations before releasing PowerPC machines.