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.