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.

John, 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? - Volodya -- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build V2: http://boost.org/boost-build2