Peter Dimov wrote:
John Maddock
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).
Is it?
Yes. See the link I posted previously.
http://www.boost.org/development/tests/trunk/developer/output/Sandia-gcc-boo...
This is Linux, _REENTRANT is not set, BOOST_HAS_THREADS is set - as far as I can see.
Ah, I think I see the issue here, and I'm not sure what the right thing to do is - if libstdc++ is built thread safe and it has threading support, then BOOST_HAS_THREADS gets turned on. We did this for two reasons: 1) Prior to gcc-4.1.2 there's nothing in the compiler defines that let you determine whether it's in multithread mode or not - we opened a gcc bug report on this ages ago, and it claims to be fixed for 4.1.2: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11953 2) In a sense gcc is either "always thread safe" or "never thread safe" depending on how it and libstdc++ were built. For example on Linux (and most other platforms I believe) -pthread does nothing except pass -lpthread to the linker. So... assuming (1) really has been fixed in gcc-4.1, what's the right thing to do about (2)? There's a school of thought which says that if gcc was built multithreaded then maybe all installed libraries should be as well "just in case". The basic issue I guess is that it may be common to build without -pthread and just add -lpthread to the linker instead? Or to try and mix code built with and without -pthread? Any thoughts...? John.