Boost logo

Boost :

Subject: Re: [boost] [config] BOOST_HAS_THREADS with libstdc++
From: John Maddock (john_at_[hidden])
Date: 2008-09-30 04:42:17

Frank Mori Hess wrote:
>> Hash: SHA1
>> It looks like the gcc bug (pr 11953) that inspired the workaround in
>> boost/config/stdlib/libstdcpp3.hpp that goes:
>> #ifdef __GLIBCXX__ // gcc 3.4 and greater:
>> # if defined(_GLIBCXX_HAVE_GTHR_DEFAULT) \
>> || defined(_GLIBCXX__PTHREADS)
>> //
>> // If the std lib has thread support turned on, then turn it on
>> in Boost // as well. We do this because some gcc-3.4 std lib
>> headers define _REENTANT
>> // while others do not...
>> //
>> was fixed for mainstream gcc 4.1.2 and later versions in December of
>> 2006. So can we change the first line to something like:
>> #ifdef __GLIBCXX__ && __GLIBCXX__<20070101
>> so detection of whether gcc is in multi-threaded mode or not works
>> again?

Probably not :-(

We had quite a long discussion about this a while back (sorry can't find the
thread right now), and the conclusion was that for Unix linke platforms, and
especially for gcc we should build and install a *single build variant*, and
that variant is thread safe if the compiler/stdlib is. I checked with the
gcc and libstdc++ developers about this, and gcc compiled code is either
always thread safe or always not thread safe depending how it was configured
and installed. Options like -pthread don't really have any effect in the
compiler - other than to define _REENTRANT - which no libstdc++ code uses -
and to select -lpthread to link to.

The plus side is that gcc compiled boost binaries are binary compatible with
whatever build options the end user selects, the down side is that to turn
off threading support you need to explicitly compile the binaries
with -DBOOST_DISABLE_THREADS. The change also means that things like
shared_ptr are binary compatible between TU's built with and without
the -pthread option, which is a big plus IMO.

HTH, John.

Boost list run by bdawes at, gregod at, cpdaniel at, john at