I took the liberty to run regressions with clang-3.2 on Win32. It's pretty unhappy, and most failures have to do with it not building shared libraries (DLLs) correctly. Not finding symbols. I found a (non-boost) thread that talks about that being a problem with it. Even so, I had a couple questions: 1. It gets labeled clang-linux-3.2, though it's under the Windows umbrella in the regression matrix. How do we fix that? user-config.jam 'using clang ;' does seem to work fine. 2. I get these warnings. They seem like clang's problem, not ours. Am I right? ..\boost/test/execution_monitor.hpp:59:7: warning: 'dllexport' attribute only applies to variables and functions [-Wignored-attributes] class BOOST_TEST_DECL translate_exception_base { ..\boost/test/detail/config.hpp:88:29: note: expanded from macro 'BOOST_TEST_DECL' # define BOOST_TEST_DECL BOOST_SYMBOL_EXPORT ..\boost/config/platform/win32.hpp:30:42: note: expanded from macro 'BOOST_SYMBOL_EXPORT' # define BOOST_SYMBOL_EXPORT __declspec(dllexport) <built-in>:154:38: note: expanded from macro '__declspec' #define __declspec(a) __attribute__((a)) 3. I tried to coerce the regression to use only static libraries (since clang does build boost static pretty well)... --bjam-options='link=static runtime-link=static' but this made some part of the regression tests very unhappy: error: link=shared together with runtime-link=static is not allowed error: such property combination is either impossible error: or too dangerious to be of any use That's understandable, as it goes against the grain. But is there a way to inform the tests somehow? It's easy to imagine wanting to explicitly test what a shared library does, but what about cases where it doesn't matter if it's shard or static? (Are they distinguishable?) If anyone's interested, please peruse the mess I made of the regression matrix. And purge them from the matrix, too, eventually.