Re: [boost] BOOST_HAS_THREADS and gcc

From: Peter Dimov (pdimov_at_[hidden])
Date: 2008-04-11 17:12:04

John Maddock:

> 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)?

Good question. :-/

We have four options for the <threading>single case:

1. !HAS_THREADS, !HAS_PTHREADS
2. HAS_THREADS, !HAS_PTHREADS
3. HAS_THREADS, HAS_PTHREADS
4. HAS_THREADS, HAS_PTHREADS, add -lpthread

I really have no idea which of these is best. I can see arguments for each. 
If .o files compiled with and without -pthread are indeed link compatible, 
our current choice of (3) seems pretty reasonable.

A practical problem I have with (3) is that pthread_mutex_trylock links and 
crashes. But I'm not sure whether this warrants any changes. Maybe the 
correct way to deal with it is to mark it up and move on.

If we do choose to stay with (3) as our choice, we probably need to revert 
the has_pthreads test back to the stubs and move the real has_pthreads (and 
has_pthread_mutexattr_settype) to separate tests outside of config_test.