On Apr 18, 2017, at 09:00:30, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
On Tue, Apr 18, 2017 at 2:22 PM, Roger Oberholtzer <roger.oberholtzer@gmail.com> wrote:
On Thu, Apr 13, 2017 at 8:04 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
13.04.2017 16:02, Roger Oberholtzer пишет:
On Thu, Apr 13, 2017 at 2:13 PM, Tom Kacvinsky <tom.kacvinsky@suse.com> wrote:
Looking at the above ldd ouput, I see that libpthread.so.0 is listed twice, the first time it is listed, it is not found, the second time it is listed, it is found. That is curious.
I agree. I don't know why there is the second reference..
Can you run the binutils tool readelf on the library?
readelf -d libfoo.so
readelf -d libuic_jpeg-1.0.so
Dynamic section at offset 0x28cf0 contains 30 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0] 0x0000000000000001 (NEEDED) Shared library: [libiomp5.so] 0x0000000000000001 (NEEDED) Shared library: [libtbb.so.2] 0x0000000000000001 (NEEDED) Shared library: [libippch.so.7.0] 0x0000000000000001 (NEEDED) Shared library: [libippdc.so.7.0] 0x0000000000000001 (NEEDED) Shared library: [libippcc.so.7.0] 0x0000000000000001 (NEEDED) Shared library: [libippcv.so.7.0] 0x0000000000000001 (NEEDED) Shared library: [libippj.so.7.0] 0x0000000000000001 (NEEDED) Shared library: [libippi.so.7.0] 0x0000000000000001 (NEEDED) Shared library: [libipps.so.7.0] 0x0000000000000001 (NEEDED) Shared library: [libippcore.so.7.0] 0x0000000000000004 (HASH) 0x1f0 0x000000006ffffef5 (GNU_HASH) 0x1250 0x0000000000000005 (STRTAB) 0x4ff0 0x0000000000000006 (SYMTAB) 0x1eb8 0x000000000000000a (STRSZ) 18275 (bytes) 0x000000000000000b (SYMENT) 24 (bytes) 0x0000000000000003 (PLTGOT) 0x229000 0x0000000000000002 (PLTRELSZ) 7992 (bytes) 0x0000000000000014 (PLTREL) RELA 0x0000000000000017 (JMPREL) 0xaa30 0x0000000000000007 (RELA) 0x9b90 0x0000000000000008 (RELASZ) 3744 (bytes) 0x0000000000000009 (RELAENT) 24 (bytes) 0x000000006ffffffb (FLAGS_1) Flags: NODEFLIB 0x000000006ffffffe (VERNEED) 0x9b70 0x000000006fffffff (VERNEEDNUM) 1 0x000000006ffffff0 (VERSYM) 0x9754 0x000000006ffffff9 (RELACOUNT) 6 0x0000000000000000 (NULL) 0x0
ldd libuic_jpeg-1.0.so linux-vdso.so.1 (0x00007ffcfdfd1000) libpthread.so.0 => not found libiomp5.so => /opt/rsoft/lib/libiomp5.so (0x00007f5cc5e61000) libtbb.so.2 => not found libippch.so.7.0 => /opt/rsoft/lib/libippch.so.7.0 (0x00007f5cc5d5a000) libippdc.so.7.0 => /opt/rsoft/lib/libippdc.so.7.0 (0x00007f5cc5c4d000) libippcc.so.7.0 => /opt/rsoft/lib/libippcc.so.7.0 (0x00007f5cc5b30000) libippcv.so.7.0 => /opt/rsoft/lib/libippcv.so.7.0 (0x00007f5cc5a0c000) libippj.so.7.0 => /opt/rsoft/lib/libippj.so.7.0 (0x00007f5cc58f8000) libippi.so.7.0 => /opt/rsoft/lib/libippi.so.7.0 (0x00007f5cc5747000) libipps.so.7.0 => /opt/rsoft/lib/libipps.so.7.0 (0x00007f5cc55df000) libippcore.so.7.0 => /opt/rsoft/lib/libippcore.so.7.0 (0x00007f5cc54c4000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f5cc52a6000) libc.so.6 => /lib64/libc.so.6 (0x00007f5cc4f01000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f5cc4cfd000) libm.so.6 => /lib64/libm.so.6 (0x00007f5cc49ea000) /lib64/ld-linux-x86-64.so.2 (0x00005615b6fbb000)
The actual question here is not why it does not find libpthread/libtbb, but how it manages to find anything in /opt/rsoft/lib.
That's easy. I have a file in /etc/ld.so.conf.d that specifies it.
That is exactly the problem - NODEFLIB should skip these paths, and it does it for other "default" paths. OTOH manual is really vague here - it says
o From the cache file /etc/ld.so.cache, which contains a compiled list of candidate shared objects previously found in the augmented library path. If, however, the binary was linked with the -z nodeflib linker option, shared objects in the default paths are skipped. Shared objects installed in hardware capability directories (see below) are preferred to other shared objects.
o In the default path /lib, and then /usr/lib. (On some 64-bit architectures, the default paths for 64-bit shared objects are /lib64, and then /usr/lib64.) If the binary was linked with the -z nodeflib linker option, this step is skipped.
if we now combine "default paths" from the first paragraph with "default path /lib and the /usr/lib" this can then be understood as "use ld.so.cache *except* /lib and /usr/lib (adjust with 64 as needed)". This then explains your situation.
Very good question; I sure learned a lot while researching it. Thank you!
Me too, thanks everyone for chiming in. Regards, Tom (who is expecting garbage at the end of my post)