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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk