It can't. The problem is that .a files do not record their direct dependencies, unlike ELF objects, and instead depend on the final link-edit having the full tree of dependencies provided, but flattened into a list. That flattening loses critical information needed to correctly resolve conflicting symbols.
The whole ELF interpreter thing is a security hole as far as I'm concerned. I'm not an expert on it but as far as I know, the existence of ELF interpreters seems to make it impossible to get a definitive list of dependencies.
I believe it would be that way, if not for performance. The linker keeps track of unresolved symbols, and resolves those symbols while parsing subsequent object files. So if you list a dependency before it is used, that dependency won’t be linked at all, resulting in unresolved symbols — thus the need for object files to be listed in a particular order.
Edit: and the need for listing a dependency twice is to resolve mutually dependent object files. If A depends on symbols from B and B depends on symbols from A, you can link A,B,A or B,A,B (per the aforementioned reasoning).
This is only a problem if the tooling to track dependencies doesn't exist.
Many programming models (e.g. monomorphization as done in C++ and Rust) are fundamentally incompatible with dynamic linking. The tooling needs to handle those cases anyway.
Yeah, it was extremely frustrating for actively changing code and not an issue for third party dependencies. I wonder what the trade offs between submodules and subtrees are for this use case.
reply