From: Vladimir Prus (ghost_at_[hidden])
Date: 2006-07-25 02:31:02
On Friday 21 July 2006 21:24, John Maddock wrote:
> The current name mangling scheme in bbv2 still doesn't match bbv1 and the
> auto-linking code. In particular if I build a library as a dll with msvc
> it doesn't get a "-mt" part in the library name, even though all builds
> against the dll runtime *are* multithreaded in msvc.
I can confirm the problem, but need your advice on the right solution.
Is the problem *only* in the naming, or it's deeper?
In V1 code, for if using dynamic link to runtime, <threading>multi is added
automatically. Is that what's desired?
Does <threading>multi have any affect of compiler (not linker) output? Is that
right that <threading>multi on msvc sets some macro that's commonly used by C
and C++ code to decide if locking should be added.
And final question -- is it really true that all code linking to dynamic
runtime should have some MT locking inside it, and pay the price for MT
locking, even if that code does not use threading at all.
Alternatively, is that true that you can build object file in
<threading>single mode, and then link it to dynamic runtime? And that in case
case, the runtime will still have MT locks, but the application itself won't,
and won't pay extra for MT support?
For example, on Linux there's just one dynamic libstdc++, which has some
locking, but it can be used just fine both by single-threaded and
multi-threaded applications. Is this different on Windows?
-- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build V2: http://boost.org/boost-build2
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk