Consider that I have an ELF shared library liba.so, which exports a symbol from_a. The implementation of from_a is defined in terms of a symbol from_b, which is exported from a shared library libb.so, and liba.so has a DT_NEEDED entry for libb.so.
I now have program, which uses the symbol from_a. When I link program, I include -la on the link line, along with whatever link-time search path, if any, is necessary for the linker to find liba.so. There are no direct dependencies on symbols from libb.so in program.
First question: is it guaranteed (in the sense of portable to all non-broken ELF using systems) that I do not need to list the indirect dependencies (in this case libb.so) of liba.so on the link line for program? I believe that this is true, but I would like to confirm. Is this behavior of the linker mandated by any specification? If so, which one (the ELF spec?)
Second question: If liba.so and libb.so are installed in a non-standard location (say $HOME/lib, as opposed to /usr/lib) that is not default searched, then when linking program, the BFD linker, at least on my current system and a few others I've tested, will complain that libb.so cannot be found, despite the fact that the library install directory is specified with -L, and suggests using -rpath or -rpath-link. However, if an RPATH or RUNPATH identifying the install location is set in liba.so, then the BFD linker is placated. Why does the BFD linker care about whether or not libb.so can be found at link time, if program has no direct dependency on it? Is the behavior obtained by setting RPATH on liba.so guaranteed? It would be nice to rely on this to placate the linker. I have also noticed that the gold linker does not fail in this case. What is the intended behavior here?
