Re: [boost] threads and gcc and BSD

From: William E. Kempf (wekempf_at_[hidden])
Date: 2003-01-24 00:14:05

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