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.