John Maddock:
OK, I've taken a shot at fixing this, but I don't have Solaris to test on, so <shrug> !
Neither do I. :-)
Basically <unistd.h> always advertises the presence of pthreads on Solaris so BOOST_HAS_PTHREADS gets set regardless. I've now added an additional check to solaris.hpp to turn it off for gcc when _PTHREADS is not set.
Yep. But won't this code in suffix.hpp: #if (defined(__MT__) || defined(_MT) || defined(_REENTRANT) \ || defined(_PTHREADS)) && !defined(BOOST_HAS_THREADS) # define BOOST_HAS_THREADS #endif turn it back on? I admit that the task of setting BOOST_HAS_THREADS is pretty hard. But the current practice of distributing the setting into compiler/platform/suffix headers seems too fragile to me. I'm not sure I understand all the subtle details yet though.
Yeh, g++ has always been lax about advertising whether it's in thread safe mode or not.
Right. My point however was that this is no longer true, starting from g++ 4.1. _REENTRANT is now being set properly (and ignored by Boost.Config). (Unfortunately intel-linux still emulates the older g++ practice of always setting _REENTRANT.)
Lets see where these changes get us, and then we need to decide what to do on Win32 in strict mode when <windows.h> is unavailable :-)
I believe that the fact that <windows.h> is unavailable (this can happen in non-strict mode as well under VC++ Express, if the Platform SDK hasn't been installed) should be indicated by a new macro that is documented as such. There's also the general problem of using BOOST_DISABLE_THREADS inside Boost.Config to communicate lack of threading support from one header to another. I don't necessarily view this as unacceptable... as long as Boost.Config is unquestionably right to do so; that is, as long as there is no situation in which the user would want to not define it. Still, the easiest way out is just to use an internal macro for communication and leave BOOST_DISABLE_* as pure user macros.