From: William E. Kempf (wekempf_at_[hidden])
Date: 2003-01-24 00:36:53
David Abrahams said:
> "William E. Kempf" <wekempf_at_[hidden]> 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:
>>> 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
>> 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
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
Option 3 would cause unecessary overhead, so doesn't sound like the right
William E. Kempf
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk