Subject: Re: [boost] cmake target and binary name mangling
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2017-07-24 23:31:47
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.