On Apr 13, 2017, at 09:02:02, Roger Oberholtzer wrote:

On Thu, Apr 13, 2017 at 2:13 PM, Tom Kacvinsky 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

Hmmm, I have never seen this in a dynamic section of a shared library: 0x000000006ffffffb (FLAGS_1) Flags: NODEFLIB I will research this to see what the effect of this flag is. I no wonder if there is something in process of using TBB that forces this flag to be in effect.

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)

...

this will give the ELF dynamic header, which should list the dependencies of the file and if there is any RUNPATH or RPATH in the shared library.

No local PATHS.

I also checked the /opt/rsoft/lib/ libs (the Intel libs) and they are the same. All 64-but, no PATHs in the lib files.

-- Roger Oberholtzer

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Thu, Apr 13, 2017 at 3:19 PM, Tom Kacvinsky wrote:

...

Hmmm, I have never seen this in a dynamic section of a shared library:

0x000000006ffffffb (FLAGS_1) Flags: NODEFLIB

I will research this to see what the effect of this flag is. I no wonder if there is something in process of using TBB that forces this flag to be in effect.

Can you see if the build process for the library in question has this option set: -z nodefaultlib. If gcc/g++ is used as the linker, the option would be -Wl,-z,nodefaultlib (or use of -Xlinker instead of -Wl)

See "man 1 ld" for more information.

Not that I see. But it does specify: -fopenmp The build i defined by Intel. They use both -fopenmp and pthread and tbb. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 13/04/2017 15:19, Tom Kacvinsky wrote:

...

...

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 Hmmm, I have never seen this in a dynamic section of a shared library:

0x000000006ffffffb (FLAGS_1) Flags: NODEFLIB

The NODEFLIB flag If the executable was linked with -z nodeflib linker option then /etc/ld.so.cache is ignored. I'm assuming that whatever uses the libraries under /opt is supposed to find them by other means. Having two libpthread's is dangerous and can cause serious problems if it's in the normal library search path. You can try setting the LD_LIBRARY_PATH LD_LIBRARY_PATH is an environment variable you set to give the run-time shared library loader (ld.so) an extra set of directories to look for when searching for shared libraries. Multiple directories can be listed, separated with a colon (:) Dave P -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

13.04.2017 16:02, Roger Oberholtzer пишет:

On Thu, Apr 13, 2017 at 2:13 PM, Tom Kacvinsky 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. 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.

...

this will give the ELF dynamic header, which should list the dependencies of the file and if there is any RUNPATH or RPATH in the shared library.

No local PATHS.

Output of "env | grep PATH" would be interesting.

I also checked the /opt/rsoft/lib/ libs (the Intel libs) and they are the same. All 64-but, no PATHs in the lib files.

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

13.04.2017 21:28, Tom Kacvinsky пишет:

...

On Apr 13, 2017, at 14:04:16, Andrei Borzenkov wrote:

13.04.2017 16:02, Roger Oberholtzer пишет:

...

On Thu, Apr 13, 2017 at 2:13 PM, Tom Kacvinsky 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.

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). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Apr 13, 2017, at 15:39:27, Andrei Borzenkov 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.

On Fri, Apr 14, 2017 at 3:04 PM, Dave Plater wrote:

On 13/04/2017 21:46, Tom Kacvinsky wrote:

...

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.

The libpthread.so that's not found most probably has NODEFLIB set.

No. libpthread that is not found is NEEDED with NODEFLIB library. libpthread that is found is NEEDED by library without NODEFLIB. NODEFLIB on libpthread itself is absolutely irrelevant here. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Apr 13, 2017, at 15:39:27, Andrei Borzenkov 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. Tom

15.04.2017 13:02, Tom Kacvinsky пишет:

...

On Apr 14, 2017, at 07:58:42, Tom Kacvinsky wrote:

...

On Apr 13, 2017, at 15:39:27, Andrei Borzenkov 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. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Thu, Apr 13, 2017 at 8:04 PM, Andrei Borzenkov wrote:

13.04.2017 16:02, Roger Oberholtzer пишет:

...

On Thu, Apr 13, 2017 at 2:13 PM, Tom Kacvinsky 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. I have always had this as it is where we put our own libraries. In this case, we have also placed the IPP libs there. We have done so for years.

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.

...

...

this will give the ELF dynamic header, which should list the dependencies of the file and if there is any RUNPATH or RPATH in the shared library.

No local PATHS.

Output of "env | grep PATH" would be interesting.

ALSA_CONFIG_PATH=/etc/alsa-pulse.conf XNLSPATH=/usr/share/X11/nls XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0 MANPATH=/usr/lib64/mpi/gcc/openmpi/share/man:/usr/local/man:/usr/share/man XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session1 PATH=/home/roger/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/opt/rsoft/bin:/opt/rsoft/bin -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Apr 18, 2017, at 09:00:30, Andrei Borzenkov wrote:

On Tue, Apr 18, 2017 at 2:22 PM, Roger Oberholtzer wrote:

...

On Thu, Apr 13, 2017 at 8:04 PM, Andrei Borzenkov wrote:

...

13.04.2017 16:02, Roger Oberholtzer пишет:

...

On Thu, Apr 13, 2017 at 2:13 PM, Tom Kacvinsky 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)

On Thu, Apr 13, 2017 at 2:39 PM, Bernhard Voelker wrote:

Architecture mismatch: 32/64 bit?

I don't think so. All libs are 64-bit. Most are from Intel's Performance Primitives. The rest are being compiled on this machine. I ran 'file' on then and got confirmation. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org