I'm trying to explain a complex problem, so bear with me.
Say I have these files
/path/build/
/path/build/liba.so
/path/build/liba.so.3 -> liba.so
/path/build/libtest.so
I even have set PATH=/path/build:... (where ... is my normal $PATH).
At some point libtest.so will load liba.so.3 at runtime.
However, liba.so.3 doesn't seem to exist when running code that (successfully) loads libtest.so, and when I ask ldd for help, I get this:
$ ldd /path/build/libtest.so
linux-vdso.so.1 => (0x00007fff24fff000)
liba.so.3 => not found
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f8fea222000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f8fe9f9e000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f8fe9d88000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f8fe9b6a000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8fe97c9000)
/lib64/ld-linux-x86-64.so.2 (0x00007f8fea767000)
(note the second output line)
How can I figure out what's going wrong? The library is clearly there, but the loader claims it's not.
Is /path/build on your LD_LIBRARY_PATH? The linux dynamic loader looks here for libraries on Linux, after the default locations
Related
I have code that was compiled with Intel version 2020.4.304 on Linux SLES 12. Over time various other versions have been added and I switched to default to OneAPI version 2021.1.1. On Windows when I update MSVS I need to update the C++ redistributable installed on any client systems.
I can switch between the loaded versions readily enough using module. When I run ldd against my executable I see that all the dependencies are fulfilled with either compiler loaded. Running the application results in the same output. This seems like undefined behavior that is just happening to work out in my favor. Here is the output from ldd (2020):
linux-vdso.so.1 (0x00007ffc17b9a000)
libifport.so.5 => /ots/sw/INTEL/2020.4/compilers_and_libraries_2020.4.304/linux/compiler/lib/intel64_lin/libifport.so.5 (0x0000150982a82000)
libifcoremt.so.5 => /ots/sw/INTEL/2020.4/compilers_and_libraries_2020.4.304/linux/compiler/lib/intel64_lin/libifcoremt.so.5 (0x0000150982d3a000)
libimf.so => /ots/sw/INTEL/2020.4/compilers_and_libraries_2020.4.304/linux/compiler/lib/intel64_lin/libimf.so (0x00001509823ff000)
libsvml.so => /ots/sw/INTEL/2020.4/compilers_and_libraries_2020.4.304/linux/compiler/lib/intel64_lin/libsvml.so (0x00001509808b5000)
libm.so.6 => /lib64/libm.so.6 (0x000015098056a000)
libintlc.so.5 => /ots/sw/INTEL/2020.4/compilers_and_libraries_2020.4.304/linux/compiler/lib/intel64_lin/libintlc.so.5 (0x00001509802f2000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00001509800cf000)
libdl.so.2 => /lib64/libdl.so.2 (0x000015097fecb000)
libc.so.6 => /lib64/libc.so.6 (0x000015097fad6000)
libgcc_s.so.1 => /ots/sw/GCC/10.2.0/lib64/libgcc_s.so.1 (0x000015097f8be000)
/lib64/ld-linux-x86-64.so.2 (0x0000150982cb0000)
And OneAPI 2021:
linux-vdso.so.1 (0x00007ffd4f2a7000)
libifport.so.5 => /ots/sw/INTEL/oneapi/2021.1/compiler/2021.1.1/linux/compiler/lib/intel64_lin/libifport.so.5 (0x00001529c1c4c000)
libifcoremt.so.5 => /ots/sw/INTEL/oneapi/2021.1/compiler/2021.1.1/linux/compiler/lib/intel64_lin/libifcoremt.so.5 (0x00001529c1f02000)
libimf.so => /ots/sw/INTEL/oneapi/2021.1/compiler/2021.1.1/linux/compiler/lib/intel64_lin/libimf.so (0x00001529c15c4000)
libsvml.so => /ots/sw/INTEL/oneapi/2021.1/compiler/2021.1.1/linux/compiler/lib/intel64_lin/libsvml.so (0x00001529bfa4b000)
libm.so.6 => /lib64/libm.so.6 (0x00001529bf700000)
libintlc.so.5 => /ots/sw/INTEL/oneapi/2021.1/compiler/2021.1.1/linux/compiler/lib/intel64_lin/libintlc.so.5 (0x00001529bf488000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00001529bf265000)
libdl.so.2 => /lib64/libdl.so.2 (0x00001529bf061000)
libc.so.6 => /lib64/libc.so.6 (0x00001529bec6c000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00001529bea53000)
/lib64/ld-linux-x86-64.so.2 (0x00001529c1e7a000)
In general are Linux libraries backwards compatible across compiler versions? Various answers and comments are somewhat contradictory. Question 1 and Question 2
In Linux, library versions are distinguished by a soname. The redistrubutable libraries from Intel should be no different if they follow the suit. If a compatibility breaking change is made, the so version number is increased so that the versions can be distinguished.
Therefore, libifport.so.5 is not compatible with libifport.so.4, but if a program requires libifport.so.5, it should be satisfied with one coming from any version of the compiler that provides it.
The changes that break backward comparibility come only in some compiler versions, certainly not every year. And since Intel has introduced new LLVM compilers and the old ones are becoming legacy, such changes may stop altogether for ifort, but that is my speculation.
Also, such change is made to a specific library or specific set of libraries, whose soname numbers are increased. Not all redistributable libraries coming with a compiler collection will be affected.
Will two libraries together produce a third library that does not even exist?
Try it here
Make sure there are icu and g++ on your machine
Output
ldd out1:
linux-vdso.so.1 (0x00007ffd5cdaf000)
liblcf.so.0 => /home/aleck099/.local/lib/liblcf.so.0 (0x00007ff200600000)
libicuuc.so.72 => /usr/lib/libicuuc.so.72 (0x00007ff200200000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007ff1ffe00000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007ff200518000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007ff2008a1000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007ff1ffc19000)
libicui18n.so.71 => not found
libicuuc.so.71 => not found
libicudata.so.71 => not found
libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007ff200874000)
libicudata.so.72 => /usr/lib/libicudata.so.72 (0x00007ff1fde00000)
/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007ff2008ea000)
ldd out2:
linux-vdso.so.1 (0x00007ffdfed78000)
libicui18n.so.72 => /usr/lib/libicui18n.so.72 (0x00007fa088000000)
libicuuc.so.72 => /usr/lib/libicuuc.so.72 (0x00007fa087c00000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007fa087800000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007fa08834d000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007fa087fe0000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007fa087619000)
libicudata.so.72 => /usr/lib/libicudata.so.72 (0x00007fa085800000)
/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fa08845e000)
You can see that three "not found"s in the ldd output of out1
They are even duplicates of existing icu libraries
How could this happen?
Other information
both clang and gcc produce the same result
liblcf.so is built from easyrpg
It looks like the link command used to create out1 picked up symbols from two different versions of the ICU library: libicuuc.so.71 and libicuuc.so.72. The 71 vs 72 is the version number. Those appear to be two different versions of the shared library that were both in the linker's library path. It's "not found" at ldd time because one copy is not in the runtime shared library search path, and even if it was mixing both is probably a bad idea.
The solution is likely to inspect your link command and ensure the -L options only include one version/copy of the ICU library.
EDIT: Linking with verbosity enabled (g++ -v option) will provide additional information about the libraries and paths being used.
Note that it's possible that some of the shared libraries pulled in by out1 are transitively pulling in the (non-existent) libicuuc.so.71. Comparing your two ldd executable outputs, I would be suspicious of /home/aleck099/.local/lib/liblcf.so.0 (and possibly /usr/lib/libexpat.so.1) that only appear in out1. The following command may help:
$ ldd /home/aleck099/.local/lib/liblcf.so.0 /usr/lib/libexpat.so.1
./a.out: error while loading shared libraries: libgraph.so.1: cannot open shared object file: No such file or directory.
ldd a.out :-inux-vdso.so.1 (0x00007ffc5bff4000) libgraph.so.1 => not found libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fa242377000) libm.so.6 => /lib64/libm.so.6 (0x00007fa242022000) libgccs.so.1 => /lib64/libgccs.so.1 (0x00007fa241e0b000) libc.so.6 => /lib64/libc.so.6 (0x00007fa241a28000) /lib64/ld-linux-x86-64.so.2 (0x00007fa2426fe000).
here i can see that libgraph.so.1 is missing what shall i do further to get that missing file.
I had this problem even with the correct libraries installed.
Try this:
sudo cp /usr/local/lib/libgraph.* /usr/lib
and compile and run again.
I used crosstools-ng to compile shadowsocks for my router, on my router, I can just ldd myExecutable to list the dependencies,
$ ssh root#my-router-ip
root#unknown:/tmp/home/root# ldd ./ss-server
libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0x2aabf000)
libm.so.0 => /lib/libm.so.0 (0x2ac23000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2ac37000)
libpthread.so.0 => /lib/libpthread.so.0 (0x2ac56000)
libc.so.0 => /lib/libc.so.0 (0x2ac78000)
libdl.so.0 => /lib/libdl.so.0 (0x2accb000)
ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x2aaa8000)
but right now I don't have my router with me, how do I check it?
tried with the tools from crosstools-ng compiled toolchain which used to compile the executable
$ mipsel-unknown-linux-uclibc-ldd /home/oglop/Downloads/ss-install/bin/ss-server
mipsel-unknown-linux-uclibc-ldd: no root given
Try `mipsel-unknown-linux-uclibc-ldd --help' for more information
$ mipsel-unknown-linux-uclibc-readelf -d /home/oglop/Downloads/ss-install/bin/ss-server
There is no dynamic section in this file.
I have already tried methods here in How to list library dependencies of a non-native binary?, none of them works.
I am trying to configure SPIKE file fuzzer on Ubuntu machine. It gives Now you need to set your LD_LIBRARY_PATH to include the path to libdisasm.so and the path to libdlrpc.so.
I did set LD_LIBRARY_PATH using export. But it is still showing up the same error again. Seems LD_LIBRARY_PATH is not working for SPIKE. How do I solve this issue.
With your LD_LIBRARY_PATH set run ldd on the fuzzer executable (I'm assuming it's an executable). It should show you the libraries that are used and potentially missing. Keeping fixing your path until all the dependencies are met.
[user#host jobs]$ ldd `which gcc`
linux-vdso.so.1 => (0x00007fff3e193000)
libm.so.6 => /lib64/libm.so.6 (0x00007fa2c1f4c000)
libz.so.1 => /lib64/libz.so.1 (0x00007fa2c1d34000)
libc.so.6 => /lib64/libc.so.6 (0x00007fa2c197d000)
/lib64/ld-linux-x86-64.so.2 (0x00007fa2c2275000)