On Wed, May 12, 2004 at 02:56:49PM +0400, Vladimir Prus wrote:
John Maddock wrote:
It looks as though _GLIBCXX_HAVE_GTHR_DEFAULT is defined by the std lib when it's in thread safe mode, so I'm leaning towards adding:
#ifdef __GLIBCXX__ // gcc 3.4 and greater: #ifdef _GLIBCXX_HAVE_GTHR_DEFAULT #define BOOST_HAS_THREADS #else #define BOOST_DISABLE_THREADS #endif #endif
To our libstdcpp3.hpp config file, which I think will take care of it, albeit not in a way that everyone will appreciate (it will force threading on whenever the std lib is also thread safe).
Ehm... I don't think Linux has single-threaded and multi-threaded versions of libstdc++ -- there's only one library installed and it's sure will be multi-threaded.
That's the default - but it is possible to configure the library without thread-safety (use --disable-threads or --enable-threads=single when compiling/configuring the library) in which case neither _REENTRANT nor _GLIBCXX_HAVE_GTHR_DEFAULT will be defined, and John's suggestion works. I'm in the middle of writing a longer reply. I think Boost's current configuration for GCC 3.4 will fail if libstdc++ is configured with non-default options or on platforms that don't use pthreads.
So, for single threaded builds 1. Boost will think it's MT build and call pthread_* functions. 2. Toolset won't add '-pthread' to linker command line
Bottom like: you'll get link failures for single-thread builds.
That's the current situation anyway, for GCC 3.4 Boost interprets _REENTRANT as meaning you're compiling a multithreaded app, but in 3.4 _REENTRANT is defined unconditionally if the compiler's thread model is "posix" (which you can see in the output of "gcc -v") jon -- "Keep away from people who try to belittle your ambitions. Small people always do that, but the really great make you feel that you, too, can become great." - Mark Twain