Open hgreving2304 opened 5 years ago
This bug also covers that as a result, symbols are looked up depth-first, instead of breadth-first.
The symbol lookup is explicitly required by the ELF standard to be done in breadth-first order, so that is a definite bug. For the loading I don't know that ELF or SYSV ABI specifies an order.
Ok. For loading, I can only say that experimentally determined, that's what the Linux loader seems to do.
See title. In certain situations, the private loader may fail to find client library dependencies. Here is an example how to reproduce:
lib_test/randomdir/lib2.c
lib_test/randomdir/lib3.c
lib_test/lib1.c
Compile and construct dependencies in lib_test/randomdir/:
Compile client and construct dependencies in lib_test/:
Now run in lib_test/:
Leads to error:
The reason for this is that the private loader follows libno2.so's dependency on libno3.so, but libno2.so is missing an rpath to search for it, see above compile cmds. Both adding randomdir to LD_LIBRARY_PATH or rpath to libno2.so works fine. Also the client lib's path is added to the search path, so it works if libno2 and libno3 are in the same path as libno1.
I have not added an example for the native loader here, but doing the same natively, the libraries are found. Using strace you can tell that the libraries are opened in breadth-first order by the loader, so the native loader sees the rpath in libno1, finding libno3.