[boost] BOOST_HAS_THREADS and gcc

From: John Maddock (john_at_[hidden])
Date: 2008-04-11 13:30:23

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-boost-bin-v2-status-config_info-test-gcc-4-2-1-debug.html
>
> 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.