|
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