Hi Anthony, Thanks for your response.

if BOOST_DISABLE_WIN32 is defined and BOOST_HAS_PTHREADS is not; the implication is that if you can't use the Windows headers, then you can't use the Windows thread API, so if we haven't got pthread-win32 configured, you can't use Boost threads.

This pretty much sums it up, yes.

I am not sure what we can do about this. One issue is that currently the thread lib requires windows.h, and therefore compiler extensions, when the library sources are built. I'm not sure whether it is safe to link something compiled with extensions on against something compiled with extensions off --- is the ABI the same? If it *is* safe, then we should remove this define from boost/config/suffix.hpp, since the boost thread headers don't explicitly include windows.h.

I think this is correct but I think the restriction only makes sense if you are building the thread library. Atleast the 1.33.1 code appears to have been written such that headers don't require language extensions. My gut feeling is that a solution like this should work: // BOOST_BUILDING is defined whenever building a boost library #if defined(BOOST_BUILDING) && defined(BOOST_MSVC) # define BOOST_REQUIRE_MSVC_LANGUAGE_EXTENSIONS #endif #include <boost/config/requires_threads.hpp> #if defined(BOOST_REQUIRE_MSVC_LANGUAGE_EXTENSIONS) # undef BOOST_REQUIRE_MSVC_LANGUAGE_EXTENSIONS #endif

OTOH, someone put the restriction there for a reason, and I wouldn't want to remove it without careful thought.

Of course. Thanks again, Sohail