Re: [boost] threads and gcc and BSD

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:
>>> ~~~~~~
>>>
>>> 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
wekempf_at_[hidden]