David Abrahams said: > "William E. Kempf" <[EMAIL PROTECTED]> writes: > >> 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. > > I don't love that idea because it ties a very boost-specific define into > the core of Boost.Build, which is really supposed to be a general build > system. How will people deal with the next such define for some other > library?
Sorry, sent prematurely. The response above was meant to be about option 1, and I fully agree that it's not a good solution (and said so in the text you deleted). To finish my thoughts on the other two options... Option 2 sounds like the right solution to me, though I'm not sure about the purpose for _REENTRANT. Is it expected that users will define this on POSIX systems, or is this a define that was expected to be defined by the implementation? Option 3 would cause unecessary overhead, so doesn't sound like the right solution. William E. Kempf [EMAIL PROTECTED] _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
