Boost logo

Boost :

Subject: Re: [boost] Including a system link library for every test, but only on mingw-w64 builds?
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2017-11-07 02:16:26

On 11/07/17 04:39, Gavin Lambert via Boost wrote:
> On 7/11/2017 10:51, Andrey Semashev wrote:
>> You can see that gcc does not support autolinking from auto_link.hpp:
> I think it's an ecosystem issue.
> One of the main reasons why MSVC can support autolinking is that by
> default the linker does not care what order libraries are linked in --
> anything in loose objects always wins over libraries, and it will search
> all the libraries for remaining unresolved symbols and error out if it
> finds symbols duplicated in multiple libraries.  Consequently Windows
> libraries generally rely on callback APIs and the like, not weak
> symbols.  (Although there are ways to use weak symbols, they're less
> popular.)
> Meanwhile ELF binaries and linkers have traditionally had a specified
> linking order, where a symbol will only resolve to a library listed
> after it.  This doesn't lend itself well to auto-linking, since it's
> harder to control the order.  They also make no distinction between
> individual .o files and a .a file containing .o files.
> (GCC does have a mode where it can link libraries in any order, similar
> to MSVC, but it's only recommended to resolve mutual dependencies and
> not for general use, since ELF libraries are more likely to rely on the
> existence of weak symbols to do link-time overrides, which in turn only
> works properly with ordered linking.)
> It's just one of those things with the weight of tradition behind it,
> and isn't likely to be "fixed" any time soon.

Exactly, only I tend to think that the ecosystem was built around the
different design of shared libraries on Windows rather than the other
way around.

Boost list run by bdawes at, gregod at, cpdaniel at, john at