OK, this is now completely solved. :-) Interestingly, boost/detail/lightweight_mutex.hpp was being included in one place and declaring lightweight_mutex from boost/detail/lwm_nop.hpp. However the implementation from boost/detail/lwm_pthreads.hpp was actually being used. To cut a long story short, declaring a prefix file that forced boost to configure itself prior to importing Cocoa and Carbon dependencies completely solved the problem. Here's what my Cocoa pch file looks like: // // Prefix header for all source files // #ifdef __cplusplus #include <boost/config.hpp> // Gets brought in early so that any Carbon presence doesn't influence // its configuration. #endif #ifdef __OBJC__ #import <Cocoa/Cocoa.h> #endif If you're doing just Carbon, then do your #include <Carbon/Carbon.h> after boost/config.hpp is included (in place of the #ifdef __OBJC__ block). The real gremlin here is this bit of code in boost/config/platform/macos.hpp: # ifndef TARGET_CARBON # include <boost/config/posix_features.hpp> # endif There is a posting that discusses the rationale of the above: http://lists.boost.org/boost-users/2004/10/8110.php and also makes the observation that there's probably a better way to check for MSL. My recommendation is to check for the definition of __MSL__. Thus the above code becomes: # ifndef __MSL__ # include <boost/config/posix_features.hpp> # endif IMHO the existing MSL check is a bug (checking TARGET_CARBON is too broad) and will be a trap for all Cocoa/Carbon programmers wanting to use boost. I would also think that the reality now is that most people use xcode/gcc and not CodeWarrior/MSL (this is from someone who used to use CW and MSL all the time). Thus, the motivation for addressing the issue should now be high. What needs to be done to fix the problem? I'm willing to help to save some other poor soul from spending a day or two stuffing around. Cheers, -C