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