Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

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.


sort by: page size:

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.


That's great, but unlike ldd, readelf won't walk the list of dependencies recursively.

AFAICS the main problem is that <string> pulls in a lot of dependencies.

Workarounds exist, like for every other example I mentioned. I am mostly referring to the commonly used dependency graph.

Probably comes down to either inline assembly or dependencies, or both.

And there's the tangling of dependencies. One fix in one lib may cause a bug in another that isn't maintained.

Hi, just on my phone but Dependencies and parrellism are supported. It's inferred from the structure of targets.

Only if it is statically linked with everything it needs. Otherwise good luck resolving dependencies.

At first it doesn't sound particularly bad... But the dependency tree that comes with it seems problematic.

It’s not that easy when you use C dependencies.

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.

It does not seem to handle dependencies.

And it checks them before checking for missing dependencies, so every time you fix a dependency, you have to do the whole rigamarole over again.

That doesn't help with transitive dependencies.

Yes! Love that about Lit. The problem is when I want to add other things that have their own dependency graph.

It is hard to be confident whether the entire dependency tree is free of this issue.

Unless you statically link your dependencies, but that comes with its own can of worms.
next

Legal | privacy