Re: [boost] Including a system link library for every test, but only on mingw-w64 builds?

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.