Boost logo

Boost :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-05-13 04:22:13


John Maddock wrote:

> > Ehm... I don't think Linux has single-threaded and multi-threaded
> > versions
>
> of
>
> > 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.

That kind of check is okay.

> > 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 really don't think we want to disable <threading>signle for such a popular
platform.

> 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,

Actually, I just don't want to pay for MT, unless I really mean to use the
code in MT environment.

> 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.

I don't really understand the problem. For example, are there any compilers
which generate MT code by default? And, what's "default for the compiler"?

> 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.

And what's the problem with that?

- Volodya


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk