[opensuse] tumbleweed not finding some .so files
I am trying to link an application that uses libpthread and libtbb. I have these installed (OPB standard packages) on an up-to-date Tumbleweed. For some reason I cannot understand, these libs are not found. When I run ldd on a program of library, I get: linux-vdso.so.1 (0x00007ffd23d17000) libpthread.so.0 => not found libiomp5.so => /opt/rsoft/lib/libiomp5.so (0x00007f82fb669000) libtbb.so.2 => not found libippch.so.7.0 => /opt/rsoft/lib/libippch.so.7.0 (0x00007f82fb562000) libippdc.so.7.0 => /opt/rsoft/lib/libippdc.so.7.0 (0x00007f82fb455000) libippcc.so.7.0 => /opt/rsoft/lib/libippcc.so.7.0 (0x00007f82fb338000) libippcv.so.7.0 => /opt/rsoft/lib/libippcv.so.7.0 (0x00007f82fb214000) libippj.so.7.0 => /opt/rsoft/lib/libippj.so.7.0 (0x00007f82fb100000) libippi.so.7.0 => /opt/rsoft/lib/libippi.so.7.0 (0x00007f82faf4f000) libipps.so.7.0 => /opt/rsoft/lib/libipps.so.7.0 (0x00007f82fade7000) libippcore.so.7.0 => /opt/rsoft/lib/libippcore.so.7.0 (0x00007f82faccc000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f82faaae000) libc.so.6 => /lib64/libc.so.6 (0x00007f82fa709000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f82fa505000) libm.so.6 => /lib64/libm.so.6 (0x00007f82fa1f2000) /lib64/ld-linux-x86-64.so.2 (0x00005617b4a56000) Looking at libtbb.so.2, I see: ldd /usr/lib64/libtbb.so.2 linux-vdso.so.1 (0x00007ffc0b5db000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f172c38e000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f172c170000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f172bde7000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f172bbcf000) libc.so.6 => /lib64/libc.so.6 (0x00007f172b828000) /lib64/ld-linux-x86-64.so.2 (0x000055804559e000) libm.so.6 => /lib64/libm.so.6 (0x00007f172b515000) So all for that lib is found. Just in case the RPMs did not do so, I ran ldconfig. So I expect the libs in /usr/lib64 to be seen. My /etc/ld.so.conf file is the default: /usr/local/lib64 /usr/local/lib include /etc/ld.so.conf.d/*.conf # /lib64, /lib, /usr/lib64 and /usr/lib gets added # automatically by ldconfig after parsing this file. # So, they do not need to be listed. I am not new to this as I use libs all over the place all the time. I have not experienced libs not being seen. Anyone have any ideas? -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Apr 13, 2017, at 07:56:08, Roger Oberholtzer <roger.oberholtzer@gmail.com> wrote:
I am trying to link an application that uses libpthread and libtbb. I have these installed (OPB standard packages) on an up-to-date Tumbleweed.
For some reason I cannot understand, these libs are not found. When I run ldd on a program of library, I get:
linux-vdso.so.1 (0x00007ffd23d17000) libpthread.so.0 => not found libiomp5.so => /opt/rsoft/lib/libiomp5.so (0x00007f82fb669000) libtbb.so.2 => not found libippch.so.7.0 => /opt/rsoft/lib/libippch.so.7.0 (0x00007f82fb562000) libippdc.so.7.0 => /opt/rsoft/lib/libippdc.so.7.0 (0x00007f82fb455000) libippcc.so.7.0 => /opt/rsoft/lib/libippcc.so.7.0 (0x00007f82fb338000) libippcv.so.7.0 => /opt/rsoft/lib/libippcv.so.7.0 (0x00007f82fb214000) libippj.so.7.0 => /opt/rsoft/lib/libippj.so.7.0 (0x00007f82fb100000) libippi.so.7.0 => /opt/rsoft/lib/libippi.so.7.0 (0x00007f82faf4f000) libipps.so.7.0 => /opt/rsoft/lib/libipps.so.7.0 (0x00007f82fade7000) libippcore.so.7.0 => /opt/rsoft/lib/libippcore.so.7.0 (0x00007f82faccc000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f82faaae000) libc.so.6 => /lib64/libc.so.6 (0x00007f82fa709000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f82fa505000) libm.so.6 => /lib64/libm.so.6 (0x00007f82fa1f2000) /lib64/ld-linux-x86-64.so.2 (0x00005617b4a56000)
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. Can you run the binutils tool readelf on the library? readelf -d libfoo.so 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.
Looking at libtbb.so.2, I see:
ldd /usr/lib64/libtbb.so.2 linux-vdso.so.1 (0x00007ffc0b5db000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f172c38e000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f172c170000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f172bde7000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f172bbcf000) libc.so.6 => /lib64/libc.so.6 (0x00007f172b828000) /lib64/ld-linux-x86-64.so.2 (0x000055804559e000) libm.so.6 => /lib64/libm.so.6 (0x00007f172b515000)
So all for that lib is found. Just in case the RPMs did not do so, I ran ldconfig. So I expect the libs in /usr/lib64 to be seen. My /etc/ld.so.conf file is the default:
/usr/local/lib64 /usr/local/lib include /etc/ld.so.conf.d/*.conf # /lib64, /lib, /usr/lib64 and /usr/lib gets added # automatically by ldconfig after parsing this file. # So, they do not need to be listed.
I am not new to this as I use libs all over the place all the time. I have not experienced libs not being seen.
Anyone have any ideas?
This makes no sense. Perhaps the library search path cache has been corrupted? Regardless of the cache, "man ld.so" says that /lib64 should be searched, regardless of the library search cache. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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)
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 Apr 13, 2017, at 09:02:02, Roger Oberholtzer <roger.oberholtzer@gmail.com> wrote:
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
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 Apr 13, 2017, at 09:16:09, Tom Kacvinsky <tom.kacvinsky@suse.com> wrote:
On Apr 13, 2017, at 09:02:02, Roger Oberholtzer <roger.oberholtzer@gmail.com> wrote:
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
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.
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
-- 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 <tom.kacvinsky@suse.com> 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 Apr 13, 2017, at 09:46:46, Roger Oberholtzer <roger.oberholtzer@gmail.com> wrote:
On Thu, Apr 13, 2017 at 3:19 PM, Tom Kacvinsky <tom.kacvinsky@suse.com> 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.
-fopenmp just instructs the compiler to honor OpneMP pragmas in the code and then link in an OpenMP library (could be Intel's or GCC's OpenMP library). What I would do is to run readelf -d on each of the libraries that is linked in and see if any of them have the NODEF option. And I would also check to see if TBB offers it's own pthreads library. I don't know enough about TBB to know any better. Since you are using TBB, you might want to file a case with Intel to see if they're doing anything special behind the scenes. They might have a linker script they're using the @<file> option, where <file> contains additional linker options. -- 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
On Apr 13, 2017, at 11:43:38, Dave Plater <dplater.list@gmail.com> wrote:
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 (:)
LD_LIBRARY_PATH will probably fix the symptom, but I think there is something screwy with The TBB build process or some other issue Not that the NEEDED entries in the dynamic header lists libpthread.so.0 exactly once, but the ldd output lists it twice, once found, once not found. So, but in TBB build process, or a bug in ld.so (which is invoked under the hood by ldd)? I used to have contacts at Intel, but alas the contact I had retired. -- 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 <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. 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
On Apr 13, 2017, at 14:04:16, 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.
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. The latter is the reason I asked for readelf to be run on all of the dependencies. But that has been answered below, so that is now a moot point. And, once again, I question the build process that NODEFLIB is set in the top level library.
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.
Indeed.
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.
I had missed this before. Sorry. N�����r��y隊Z)z{.�ﮞ˛���m�)z{.��+�: �{Zr�az�'z��j)h���Ǿ� ޮ�^�ˬz��
13.04.2017 21:28, Tom Kacvinsky пишет:
On Apr 13, 2017, at 14:04:16, 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.
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
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. -- 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 <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.
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. Dave P
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, Apr 14, 2017 at 3:04 PM, Dave Plater <dplater.list@gmail.com> 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 Fri, Apr 14, 2017 at 2:46 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote: I hunted through the various shell scripts that the intel package uses to make the libraries. I removed the -z nodeflibs option. Now I get the more correct: linux-vdso.so.1 (0x00007ffc1ad96000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f663bceb000) libiomp5.so => /opt/rsoft/lib/libiomp5.so (0x00007f663b9f9000) libtbb.so.2 => /usr/lib64/libtbb.so.2 (0x00007f663b7bc000) libippch.so.7.0 => /opt/rsoft/lib/libippch.so.7.0 (0x00007f663b6b5000) libippdc.so.7.0 => /opt/rsoft/lib/libippdc.so.7.0 (0x00007f663b5a8000) libippcc.so.7.0 => /opt/rsoft/lib/libippcc.so.7.0 (0x00007f663b48b000) libippcv.so.7.0 => /opt/rsoft/lib/libippcv.so.7.0 (0x00007f663b367000) libippj.so.7.0 => /opt/rsoft/lib/libippj.so.7.0 (0x00007f663b253000) libippi.so.7.0 => /opt/rsoft/lib/libippi.so.7.0 (0x00007f663b0a2000) libipps.so.7.0 => /opt/rsoft/lib/libipps.so.7.0 (0x00007f663af3a000) libippcore.so.7.0 => /opt/rsoft/lib/libippcore.so.7.0 (0x00007f663ae1f000) libc.so.6 => /lib64/libc.so.6 (0x00007f663aa7a000) /lib64/ld-linux-x86-64.so.2 (0x000055d68d51b000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f663a876000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f663a4ed000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f663a2d5000) libm.so.6 => /lib64/libm.so.6 (0x00007f6639fc2000) I am curious why they may have used the flag. I will have no problem (I think) ensuring that the correct libs are used. But it makes me wonder what the original reason for using it might have been. -- Roger Oberholtzer -- 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 <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. Tom
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?
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. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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.
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. 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 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! -- 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 <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)
On 04/13/2017 01:56 PM, Roger Oberholtzer wrote:
I am trying to link an application that uses libpthread and libtbb. I have these installed (OPB standard packages) on an up-to-date Tumbleweed.
For some reason I cannot understand, these libs are not found. When I run ldd on a program of library, I get:
linux-vdso.so.1 (0x00007ffd23d17000) libpthread.so.0 => not found libiomp5.so => /opt/rsoft/lib/libiomp5.so (0x00007f82fb669000) libtbb.so.2 => not found libippch.so.7.0 => /opt/rsoft/lib/libippch.so.7.0 (0x00007f82fb562000) libippdc.so.7.0 => /opt/rsoft/lib/libippdc.so.7.0 (0x00007f82fb455000) libippcc.so.7.0 => /opt/rsoft/lib/libippcc.so.7.0 (0x00007f82fb338000) libippcv.so.7.0 => /opt/rsoft/lib/libippcv.so.7.0 (0x00007f82fb214000) libippj.so.7.0 => /opt/rsoft/lib/libippj.so.7.0 (0x00007f82fb100000) libippi.so.7.0 => /opt/rsoft/lib/libippi.so.7.0 (0x00007f82faf4f000) libipps.so.7.0 => /opt/rsoft/lib/libipps.so.7.0 (0x00007f82fade7000) libippcore.so.7.0 => /opt/rsoft/lib/libippcore.so.7.0 (0x00007f82faccc000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f82faaae000) libc.so.6 => /lib64/libc.so.6 (0x00007f82fa709000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f82fa505000) libm.so.6 => /lib64/libm.so.6 (0x00007f82fa1f2000) /lib64/ld-linux-x86-64.so.2 (0x00005617b4a56000)
...
Anyone have any ideas?
Architecture mismatch: 32/64 bit? Have a nice day, Berny -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Apr 13, 2017 at 2:39 PM, Bernhard Voelker <mail@bernhard-voelker.de> 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
On Apr 13, 2017, at 08:39:52, Bernhard Voelker <mail@bernhard-voelker.de> wrote:
On 04/13/2017 01:56 PM, Roger Oberholtzer wrote:
I am trying to link an application that uses libpthread and libtbb. I have these installed (OPB standard packages) on an up-to-date Tumbleweed.
For some reason I cannot understand, these libs are not found. When I run ldd on a program of library, I get:
linux-vdso.so.1 (0x00007ffd23d17000) libpthread.so.0 => not found libiomp5.so => /opt/rsoft/lib/libiomp5.so (0x00007f82fb669000) libtbb.so.2 => not found libippch.so.7.0 => /opt/rsoft/lib/libippch.so.7.0 (0x00007f82fb562000) libippdc.so.7.0 => /opt/rsoft/lib/libippdc.so.7.0 (0x00007f82fb455000) libippcc.so.7.0 => /opt/rsoft/lib/libippcc.so.7.0 (0x00007f82fb338000) libippcv.so.7.0 => /opt/rsoft/lib/libippcv.so.7.0 (0x00007f82fb214000) libippj.so.7.0 => /opt/rsoft/lib/libippj.so.7.0 (0x00007f82fb100000) libippi.so.7.0 => /opt/rsoft/lib/libippi.so.7.0 (0x00007f82faf4f000) libipps.so.7.0 => /opt/rsoft/lib/libipps.so.7.0 (0x00007f82fade7000) libippcore.so.7.0 => /opt/rsoft/lib/libippcore.so.7.0 (0x00007f82faccc000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f82faaae000) libc.so.6 => /lib64/libc.so.6 (0x00007f82fa709000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f82fa505000) libm.so.6 => /lib64/libm.so.6 (0x00007f82fa1f2000) /lib64/ld-linux-x86-64.so.2 (0x00005617b4a56000)
...
Anyone have any ideas?
Architecture mismatch: 32/64 bit?
Yeah, could be that, and it might be due to an embedded RPATH, which is why I suggested finding out what is in the dynamic header of the shared library. If there is an RPATH, it can be removed via chrpath --delete. All one needs to do is "zypper in chrpath" and away you go. We mgith also need information on how the library is built, but we'll cross that bridge if we need to. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 13.04.2017 13:56, Roger Oberholtzer wrote:
I am trying to link an application that uses libpthread and libtbb. I have these installed (OPB standard packages) on an up-to-date Tumbleweed.
For some reason I cannot understand, these libs are not found. When I run ldd on a program of library, I get:
linux-vdso.so.1 (0x00007ffd23d17000) libpthread.so.0 => not found libiomp5.so => /opt/rsoft/lib/libiomp5.so (0x00007f82fb669000) libtbb.so.2 => not found
you could try to run strace -f -e open my_binary to watch the program search for the libraries.
participants (6)
-
Andrei Borzenkov -
Bernhard Voelker -
Dave Plater -
Florian Gleixner -
Roger Oberholtzer -
Tom Kacvinsky