[PATCH] D108006: [lld][ELF] Add --no-search-static-libs-for-shlib-undefined flag

[Peter Smith via Phabricator via llvm-commits]

peter.smith added a comment.

I'm probably not going to be of much help here. I think this falls into implementation defined behaviour. My understanding is that the intention from the ELF dynamic library designers was to mimic the semantics of static libraries, we can all argue to what degree they succeeded by that, but anyway; if we follow that through we'd expect that a programmer ought to be able to substitute a static library for a dynamic library and not to have to make any modifications. Under that argument then undefined symbols from shared libraries should extract symbols from static libraries.

A possible counter argument could run from DT_NEEDED. Consider the following example:

- dso1.so has a reference to symbol foo
- dso1.so has a DT_NEEDED tag for dso2.so
- dso2.so defines symbol foo
- static.a contains an object that defines foo
- If we static link in the DT_NEEDED order `dso1.so dso2.so` then we'd expect dso2.so to define foo and no object will be extracted from static.a
- If we don't follow the DT_NEEDED order `dso1.so static.a dso2.so` or if we elide dso2.so `dso1.so static.a` then the linker will extract foo from the object in static.a

In a static linker with no back references then this would be solvable by the programmer putting dso2.so after dso1.so. With back references it gets to be a bit more complicated. For example consider `static.a dso1.so dso2.so` it may be more difficult to reason about the order. I'm not sure I can come up with an example where it is not possible to put the libraries on the command line on the right order to get the right answer. However I'm not sure that this is a good argument for not extracting symbols from static libraries.

To me this is similar to the argument around back-references. If someone has a program that depends on no back-references, then they are going to be upset when a different linker says my implementation choice is to support back-references. I think we are looking at a request to support Gold's implementation choice (assuming Gold does not search static libraries for dynamic dependencies). We've got two possible responses:

- Yes, the change is small and is not likely to be a maintenance burden. It helps people migrate from Gold. While changing link order should be easy, working with build systems is hard.
- No, this affects a small number of programs, we don't want the maintenance burden, they should alter their program structure or maintain a downstream patch.

FWIW in Arm's old proprietary linker we had to support both as we were trying to support Symbian and ELF (Linux) dynamic linking, and Symbian required no searching and some ELF programs required searching.

If you're leaning towards no, is there anything that we can do to help Android find the programs that may need altering. If we find a case where no amount of link order tweaking will work then it strengthens the case supporting the Gold behaviour, if we can fix all cases by reordering the link line then we may be able to get away without it.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D108006/new/

https://reviews.llvm.org/D108006