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: Gavin Lambert (gavinl_at_[hidden])
Date: 2017-11-07 01:39:04

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.