On Apr 13, 2017, at 15:39:27, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
13.04.2017 21:42, Andrei Borzenkov пишет:
ldd starts with libuic_jpeg-1.0.so that has NODEFLIB flags, so it fails to find those that are not in /opt/rsoft/lib (how it finds something in /opt/rsoft/lib is still a mystery). Then it continues with further dependencies of found libraries. These now apparently do not have NODEFLIB flag so it finds them in standard places.
Could be LD_LIBRARY_PATH is set, could be one of the dependencies has an RPATH set.
How RPATH further down the chain is relevant? From libpthread to libippcore we have direct dependencies. Where there are looked for is determined solely by information in libuic_jpeg-1.0.so and probably LD_LIBRARY_PATH. As library apparently does not have RPATH defined, it is the only possibility (unless ldd itself isets it. Actually, "which ldd" could be interesting as well).
Here is trivial example:
bor@bor-Latitude-E5450:/tmp$ LC_ALL=C LANG=C readelf -d liba.so
Dynamic section at offset 0xde8 contains 27 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [libb.so] 0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] ... 0x000000006ffffffb (FLAGS_1) Flags: NODEFLIB ... bor@bor-Latitude-E5450:/tmp$ LC_ALL=C LANG=C readelf -d libb.so
Dynamic section at offset 0xe08 contains 25 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] ... [skipped, no NODEFLIB] ... bor@bor-Latitude-E5450:/tmp$ LC_ALL=C LANG=C ldd liba.so linux-vdso.so.1 => (0x00007ffe237ba000) libb.so => not found libpthread.so.0 => not found libc.so.6 => not found bor@bor-Latitude-E5450:/tmp$ LC_ALL=C LANG=C LD_LIBRARY_PATH=. ldd liba.so linux-vdso.so.1 => (0x00007fff49bc0000) libb.so => ./libb.so (0x00007f07b9051000) libpthread.so.0 => not found libc.so.6 => not found libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f07b8e0a000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f07b8a41000) /lib64/ld-linux-x86-64.so.2 (0x000055d3c04b4000)
Or with RPATH
bor@bor-Latitude-E5450:/tmp$ LC_ALL=C LANG=C readelf -d libb.so
Dynamic section at offset 0xdf8 contains 26 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x000000000000000f (RPATH) Library rpath: [/tmp] ... bor@bor-Latitude-E5450:/tmp$ LC_ALL=C LANG=C LD_LIBRARY_PATH=. ldd liba.so linux-vdso.so.1 => (0x00007ffe663e2000) libb.so => ./libb.so (0x00007f0e0cd9d000) libpthread.so.0 => not found libc.so.6 => not found libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f0e0cb56000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0e0c78d000) /lib64/ld-linux-x86-64.so.2 (0x0000561e90142000)
So RPATH in libb does not affect library search for liba.
Yes sir, you are correct. I had forgotten that RPATH is not recursive. Well, I guess the only thing left is to figure out why the top level library has NODEFLIB set, which I've been trying to get an answer to. And, the other confusing thing is why the top level library lists libpthread.so only once in the NEEDED section, yet ldd reports it twice, once found, once not found. I am not sure why that would happen.