On Apr 15, 2017, at 07:24:04, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
15.04.2017 13:02, Tom Kacvinsky пишет:
On Apr 14, 2017, at 07:58:42, Tom Kacvinsky <tom.kacvinsky@suse.com> wrote:
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)
Interesting thing about your test cases (both with and without NODEFLIB) is that libc and libpthread are found and not found - Schrödinger's libraries!
I also note that TW is doing something different with the system library locations - instead of /lib64 being the location where libc and libpthread are located, they are found in /lib/x86_64-linux-gnu. I am not surprised by this, Linux has been moving towards this for quite sometime now. So I wonder if there is something going on with ld.so and this "new" library location layout.
This is extremely odd. I have been using Leap 42.1, but got around to installing TW today. My installation has no such directory /lib/x86_64-linux-gnu. This is with the latest patches, etc..
So package do I install to get this directory setup? Or did this change recently and that directory structure no longer exists?
This example was from Ubuntu.
Ah yes, I have definitely seen that on Ubuntu systems at a previous job. So what is an Ubuntu question/answer doing on an opensuse list? More curious than anything.