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
// Gets brought in early so that any
Carbon presence doesn't influence
// its configuration.
#endif
#ifdef __OBJC__
#import
#endif
If you're doing just Carbon, then do your #include
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
# 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
# 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
