Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk