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
~~~~~~~~~~~
Any other ideas?
John Maddock
http://ourworld.compuserve.com/homepages/john_maddock/index.htm
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
