John Maddock said: > I think I may be the one who broke a lot of the OpenBSD regression tests > by defining BOOST_HAS_PTHREADS in the OpenBSD platform configuration. > IMO this is correct (OpenBSD supports pthreads right?), but it causes a > problem: currently the gcc config unconditionally defines > BOOST_HAS_THREADS, basically because we didn't know what else to do (gcc > on *BSD doesn't define anything when you build with -pthread - basically > defining -pthread affects only the linker, so we can't detect when to > turn on threading support). This in turn is breaking a lot of libraries: > mainly those that depend upon smart pointers, which do internal thread > synchronisation, and therefore need the -pthread option in order to link > correctly. > > What should we do about this? > > Option 1: > ~~~~~~ > > would putting: > > flags gcc CFLAGS <threading>single : -DBOOST_DISABLE_THREADS ; > > fix the problem? > > Option 2: > ~~~~~~ > > Add > > flags gcc CFLAGS <threading>multi : -pthread -D_REENTRANT ; > > to the toolset, and stop defining BOOST_HAS_THREADS unconditionally for > gcc. This one may have all sorts of unexpected side effects on other > platforms though - even though philosophically it does seem the right > thing to do. > > Option 3: > ~~~~~~ > > Make -pthread the default build option in the gcc toolset for *BSD > platforms > > ~~~~~~~~~~~
Seems to me like this should be reversed. Have the config headers unconditionally NOT define BOOST_HAS_THREADS, and have the Jam toolsets define it when threading is requested. The reasoning is how this will work/effect people using Boost in their own projects when they do not use Jam for building. But even this is an unatractive solution. William E. Kempf [EMAIL PROTECTED] _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
