On 24/07/2017 10:23, Niall Douglas wrote:
So everything you just said is all irrelevant. Meanwhile, there are *enormous* end user gains to mangling the binary name. Even I who has been at this game twenty plus years now I still accidentally link a binary compiled one way with binaries compiled an incompatible way, and then spent hours - occasionally days - scratching my head as to what is wrong. Indeed it only happened to me again a few days ago where I mixed a clang LLVM compiled binary with a MSVC compiled binary. Bad idea.
Name mangling of library outputs is a universal good. It's why Boost does it, and any sane cmake does it. After all, why else has cmake generator expression support for name mangling? And if you're not doing it where you code, with respect I suggest you need a ton load more automated tooling deployed where you work, because you obviously are not doing enough testing or the right testing.
FWIW, for Windows compiles I use auto-linking, and then have a script examine the import table of the resulting binaries to extract the names of the libraries thus auto-linked-to in order to determine which DLLs need to be included in installation scripts and the like. So it's basically all automatic and I don't really ever need to care what the libraries are called, as long as they *do* have mangled names (and thus alternate versions can co-exist in the same target folder). Linux is actually a little more painful, because it doesn't have auto-linking and none of its auto-naming conventions really fit what's really important. Generally speaking Linux is a bit less picky about linking modules built with different compilers or different versions together -- up to a point, that point being which libc gets linked in. But there isn't an option to mangle the name based on the libc version, just the compiler version.