Frank Mori Hess wrote:
-----BEGIN PGP SIGNED MESSAGE----- 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... // # define BOOST_HAS_THREADS
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.