Boost logo

Boost :

From: John Maddock (john_at_[hidden])
Date: 2004-05-12 06:48:34

> > It looks as though _GLIBCXX_HAVE_GTHR_DEFAULT is defined by the std lib
> > when it's in thread safe mode, so I'm leaning towards adding:
> >
> > #ifdef __GLIBCXX__ // gcc 3.4 and greater:
> > #else
> > #endif
> > #endif
> >
> > To our libstdcpp3.hpp config file, which I think will take care of it,
> > albeit not in a way that everyone will appreciate (it will force
> > on whenever the std lib is also thread safe).
> Ehm... I don't think Linux has single-threaded and multi-threaded versions
> libstdc++ -- there's only one library installed and it's sure will be
> multi-threaded.

Not quite, it's determined by how you installed and configured the compiler
whether it's thread safe or not, hense the check, at the very least if it's
not thread safe then we'd better not turn on threading support whatever.

> So, for single threaded builds
> 1. Boost will think it's MT build and call pthread_* functions.
> 2. Toolset won't add '-pthread' to linker command line
> Bottom like: you'll get link failures for single-thread builds.

We can fix that: we already have platforms/toolsets where the default, in
fact the *only* behaviour is for builds to be thread safe, even if you
specify <threading>single.

I think the problem here is that we have two options for the <threading>
variant, but really we should have three:

1) threading must be on
2) threading must be off
3) whatever the default is for the compiler

Most people actually want option (3) a lot of the time, and currently that's
what <threading>single more or less gives you, ideally though we would map
builds for option 3 to either 1 or 2 so we don't build libraries we've
actually already built. This happens at the moment for example with MSVC
where <runtime-link>dynamic implies <threading>multi, and any other option
for the <threading> variant gets ignored.


Boost list run by bdawes at, gregod at, cpdaniel at, john at