C++ without Boost is like Oktoberfest without brass music & bier- no fun at all. This is true for the Mac, too, but there are some specific problems.
Getting to work with boost under XCode did cost me some grey hair. Here are my experiences which might save you some time.
Obtain the sources from boost.org or sourceforge. Read the instructions on how to build. 1_52 is broken for Mac, see here. 1_51 and 1_53 are fine. Symptom you are affected are messages like "error: constexpr function never produces a constant expression".
Building for Both 32/64 bits
If you need to support both architectures, you can do it if you create a file named ~/user-config.jam with these two lines:
using darwin : : : <compileflags>"-arch x86_64 -arch i386" ;
using clang : : : <compileflags>"-arch x86_64 -arch i386 -stdlib=libc++" ;
The first line makes sure a regular build is with both 64/32 bit libraries. The libraries such created are Mac "fat" libraries, containing both variants in one file.
Building for CLang
If you build like instructed on the boost website, the libraries are fine for g++, but not clang++, the compiler used by default by XCode. You can build libraries for use with XCode with this line:
This is made possible by the second line in user-config.jam. Again, this builds fat binaries. If you try to build a binary with clang++ , but your boost is build with g++, you will get error messages like:
"Undefined symbols for architecture i386:
std::__1::allocator<char> > const&)", referenced from:”
Building for iOS
If you need boost for iOS, you can find instructions by Pete Goodliffe here. Pete wrote a nifty shell script to do the job which you can find here. It's a bit dated, though, and I had to make a few minor changes so it works with the current SDK version 6.1 (as of Mar. 2013). The updated version of the script is attached to this tip. This zip includes a user-config.jam which you need to put in your home directory.
Note that both boost and some Apple includes define a Macro "check”. This can cause errors like the one encountered here. I circumvent this problem by adding:
just before I include the boost headers. The Apple headers Carbon/Carbon.h etc. are all included before. There is another, maybe better possibility described in AssertMacros.h.
* Prior to Mac OS X 10.6 the macro names used in this file conflicted with some
* user code, including libraries in boost and the proposed C++ standards efforts,
* and there was no way for a client of this header to resolve this conflict. Because
* of this, most of the macros have been changed so that they are prefixed with
* __ and contain at least one capital letter, which should alleviate the current
* and future conflicts. However, to allow current sources to continue to compile,
* compatibility macros are defined at the end with the old names. A tops script
* at the end of this file will convert all of the old macro names used in a directory
* to the new names. Clients are recommended to migrate over to these new macros as
* they update their sources because a future release of Mac OS X will remove the
* old macro definitions ( without the double-underscore prefix ). Clients who
* want to compile without the old macro definitions can define the macro
* __ASSERT_MACROS_DEFINE_VERSIONS_WITHOUT_UNDERSCORES to 0 before this file is
You are affected by this if you encounter errors like:
Expected member name in has_binary_operator.hpp