Building boost on Mac OS X 10.6

Today I finally had the time to verify that the problems building boost on Mac OS X 10.6 aka Snow Leopard using the compiler enclosed in XCode-3.2 were over. And indeed, building boost 1.42.0 is a nobrainer: just unpack and build.

I’ve built it with these options:

bjam --build-dir=../boost_build --layout=versioned toolset=darwin architecture=combined address-model=32_64 link=shared,static stage

Building boost on Mac OS X 10.6 with XCode 3.2

Getting boost to build in ‘fat binaries’ is a pain when you’ve just switched to XCode 3.2. Switching to XCode 3.2 is somewhat obligatory, because that also brings you the SDK for Mac OS X 10.6, aka Snow Leopard. And when you run the Snow Leopard, you want the SDK for it as well. It sounds so simple.

The Apple version of gcc, included in XCode, stops building boost in fat versions, it works for targeted versions (i.e. with only one architecture). But, if you want to build ‘universal’ binaries that work in 64bit and 32bit mode, you’re out of luck.

I got it to build this morning, thanks to some discussions on the boost mailing list. And it == boost 1_40_0, with XCode 3.2 on Snow Leopard.

This is the command-line I used:

bjam --build-dir=../boost_build --layout=versioned toolset=darwin architecture=combined address-model=32_64 link=shared,static install

And here is the patch I created to get it to work. It boils down to: remove all the ppc entries from the tools/build/v2/tools/darwin.jam, because the XCode compiler does not offer support for PPC anymore. And, you have to remove the “-m64” option in the gcc.jam, because the xcode compiler does not like to have -arch x86_64 -arch i386 -m64 all together on the command-line.

But, if you take the road of building your code on XCode 3.2, you specifically eliminate all those users still using a PPC based Mac. That might not be what you intended. In that case you probably need to add the -V 4.0.1. option to gcc/g++ in which case you use the older compiler (from XCode 3.1), which might or might not be what you need for your project.

(Sorry for the stupid looks on the patch, but wordpress mangles stuff with the <code> tag).

diff --recursive -u boost_1_40_0.orig/tools/build/v2/tools/darwin.jam boost_1_40_0/tools/build/v2/tools/darwin.jam
--- boost_1_40_0.orig/tools/build/v2/tools/darwin.jam 2009-04-14 09:59:30.000000000 +0200
+++ boost_1_40_0/tools/build/v2/tools/darwin.jam 2009-09-06 08:01:26.000000000 +0200
@@ -304,9 +304,9 @@
: $(values) ;

-arch-addr-flags darwin OPTIONS : combined : 32 : -arch i386 -arch ppc : default ;
-arch-addr-flags darwin OPTIONS : combined : 64 : -arch x86_64 -arch ppc64 ;
-arch-addr-flags darwin OPTIONS : combined : 32_64 : -arch i386 -arch ppc -arch x86_64 -arch ppc64 ;
+arch-addr-flags darwin OPTIONS : combined : 32 : -arch i386 : default ;
+arch-addr-flags darwin OPTIONS : combined : 64 : -arch x86_64 ;
+arch-addr-flags darwin OPTIONS : combined : 32_64 : -arch i386 -arch x86_64 ;

arch-addr-flags darwin OPTIONS : x86 : 32 : -arch i386 : default ;
arch-addr-flags darwin OPTIONS : x86 : 64 : -arch x86_64 ;
diff --recursive -u boost_1_40_0.orig/tools/build/v2/tools/gcc.jam boost_1_40_0/tools/build/v2/tools/gcc.jam
--- boost_1_40_0.orig/tools/build/v2/tools/gcc.jam 2009-07-11 13:04:31.000000000 +0200
+++ boost_1_40_0/tools/build/v2/tools/gcc.jam 2009-09-06 08:11:17.000000000 +0200
@@ -375,7 +375,8 @@
- option = -m64 ;
+ # option = -m64 ;
+ option = ;
OPTIONS on $(targets) += $(option) ;


TheMacBundles has an offer for a few utilities which are quite nice. But the killerapp, parallels, I’ve already bought, so that’s sort of an un-offer for me. Also, the rest of the tools doesn’t quite appeal to me, mostly because the tools replace some other shareware of payware tool I’ve already got.

One thing made me curious though: DragThing. I’ve had it on my mac before, but I dismissed it rather swiftly the first time around. And I couldn’t think of any reason why I did that in the first place. So, this article contains my testingresults for the DragThing tool.

First off, DragThing is supposed to be a Dock replacement. Some people don’t like the dock, at all. Personally I’m rather indifferent. It’s nice to know which applications are running at any given time, and for that purpose it works. I use too many tools, like shells, mail, browser, textmate, etc. open in various configurations that I’m not using the dock for keeping the most-frequently used tools (other than mail (postbox at the moment, but that’s for another article) and safari. Which got upgraded today to a real 4.0, instead of 4beta. It didn’t crash, so that counts as good). I’m really not using the document stacks.

In DragThing, you can keep drawers for your apps, documents, folders, urls etc. All nicely together in a thing called a Dock. Of which you can run two incarnations (in the non-paid-for version): one for holding apps, docs, etc and one for the ProcessDock, which has a list of all running processes. The paid-for version also has a disk and window dock, which might come in handy when you have too many safari windows open. Personally I don’t expect much from that, because I use tabbed browsing, so I don’t have many windows open from one application.

You can associate hotkeys with certain things you want to have done, but, frankly, I’m all out of hotkeys right now. Probably the first thing I’m really needing is a two-key hotkey (like emacs with Control-x as prefix), but that’s a topic for another time.

All in all, I’m of the opinion that DragThing is not what I need to manage the stuff I do. It’s not particularly nice looking (a big, who cares topic, but on a mac, well, I do care), and the other needs aren’t that big to have them satisfied by purchasing DragThing.