Hi John, Thank you for your response.

This may prove to be a tricky one: I think we can safely link to the thread lib when building with /Za, but I suspect that there are other libraries that depend on BOOST_HAS_THREADS as well: in fact a quick search through the headers showed rather a lot of uses, some relate to use of Boost.Threads, but many don't.

Currently I'm of the (possibly misguided) opinion that the issue is not really whether or not one has the thread library, but whether or not language extensions are required to use header XYZ. That could be the easier solution, if it is indeed the right one. And it could be applied on a per-library basis as needed.

I guess we could invent a new macro BOOST_HAS_THREAD_LIB or something, but then to be consistent, we would have to change some but not all uses of BOOST_HAS_THREADS in other libraries to this new macro. Tricky to get it all right.

Also, haven't some of the Boost.Thread components become header only now? Will these still work with /Za?

I hope they do! Perhaps running tests should disallow language extensions (via /Za)? I can imagine a lot of boost users need to run on different compilers/platforms and having language extensions turned off will help. As a side note, it seems that MSVC 8 turns language extensions *on* by default. It has been jokingly said that /Za is deprecated ;) Sohail