I tried working my way through the config headers and got TOTALLY lost. I tried -H, -E and #warning before I gave up and submitted this missive. Even if you can provide the answer "off the top of your head", would you mind providing a pointer or two toward the correct path to finding the problem? I'd appreciate that at least as much as the solution itself.
If you look at the line that triggers the #error, you will see it is within a block scoped by: #elif !defined(BOOST_HAS_THREADS) so the error is triggered by BOOST_HAS_THREADS not being defined. If you now grep through the boost/config headers you will see: In suffix.hpp: #if (defined(__MT__) || defined(_MT) || defined(_REENTRANT) \ || defined(_PTHREADS)) && !defined(BOOST_HAS_THREADS) # define BOOST_HAS_THREADS #endif Which is the catch-all case - for gcc on linux, if threading support has been enabled in the compiler then _REENTRANT is usually defined, clearly it's not in your case, unless that is BOOST_HAS_THREADS is being #undef'ed later on by: #if defined(BOOST_HAS_THREADS) && !defined(BOOST_HAS_PTHREADS)\ && !defined(BOOST_HAS_WINTHREADS) && !defined(BOOST_HAS_BETHREADS)\ && !defined(BOOST_HAS_MPTASKS) # undef BOOST_HAS_THREADS #endif Which is there in case the config system doesn't know what kind of threading support the platform uses (pthreads win32 threads mptasks etc). If this is the case it's probably because unistd.h doesn't advertise pthread support with _POSIX_THREADS. Also note: for OS'es that are not linux, threading support may get turned on unconditionally in gcc.hpp (I don't think this is relevant here), also for gcc 3.4 and later, threading support is turned on or else forced off in libstdc++.hpp depending on how your std lib was built. To find out which of the above is the cause the easiest way I find is to through some #errors in the preprocessor branches you think may be taken and then see if the #error is triggered or not (this is much easier than preprocessing the code IMO). To help you more we probably need: The gcc version. The command line that produced the above error. The output from the config_info program (cd into libs/config/test then "bjam -sBUILD="<threading>multi" config_info", then look for output the program generated somewhere under boost-path/bin/boost/libs/config/test/config_info/ ...some directories... /*.output Hope this gets you further forward. John.