Meaning of "cannot open shared object file" - shared-libraries

My executable compiles, but then fails to run saying he cannot load a shared library. But the named library is right there (and LD_LIBRARY_PATH is set to right here too); and both objects are 64b.
$ l
-rwxrwxr-x 1 dario dario 13M May 2 17:46 pose-estimator*
-rw-rw-r-- 1 dario dario 12K May 2 19:52 Makefile
-rwxr-xr-x 1 dario dario 6.0M May 2 20:06 libmyelin.so.1*
$ make
[100%] Built target pose-estimator
$ pwd
/home/dario/nethra-pose-estimation/build
$ echo $LD_LIBRARY_PATH
/home/dario/nethra-pose-estimation/build
$ file pose-estimator libmyelin.so.1
pose-estimator: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/l, for GNU/Linux 3.2.0, BuildID[sha1]=598251a1370ca6547010a0c5d712738b4a698e57, with debug_info, not stripped
libmyelin.so.1: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=c83470883245833a03e26dd8f1e4a23a5eb9c512, stripped
$ ./pose-estimator
./pose-estimator: error while loading shared libraries: libmyelin.so.1: cannot open shared object file: No such file or directory
What?
Why is the dynamic linker complaining with "error while loading shared libraries: libmyelin.so.1: cannot open shared object file: No such file or directory" ?
What's the next debug step to resolve this issue?

Who is complaining with "error while loading shared libraries: libmyelin.so.1: cannot open shared object file: No such file or directory" ?
The dynamic linker is.
What's the next debug step to resolve this issue?
Run file pose-estimator libmyelin.so.1. Chances are that one of them is 64-bit (x86_64) while the other is 32-bit (i386).
Update:
My guess was somewhat wrong: both files are for x86_64. But this file
libmyelin.so.1: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=c83470883245833a03e26dd8f1e4a23a5eb9c512, stripped
has the wrong (OS/ABI): ELFOSABI_SYSV instead of (expected) ELFOSABI_GNU. Runtime loader ignores files from "foreign" OSes.
P.S. Your pose-estimator appears to be corrupt: interpreter /lib64/l should be interpreter /lib64/ld-linux-x86-64.so.2.

Fixed. The error is uninformative. When pointing LD_LIBRARY_PATH to TensorRT-7.0.0.11/lib/ (which has other libraries needed) it runs.
So, if nothing seems to work for you (like it did for me) research the library that the dynamic linker is complaining about, verify if it is part of a greater whole, and the point LD_LIBRARY_PATH to the location with that family of libraries.

Related

why i can not run program on my linux(qemu simulate arm32,and start a linux os)

【1】, I have a linux os environment, which is based on arm32(qemu similute).
【2】, There are two file in / directory. One is "init", and one is "nesoft", but i can only run "init", and i can not run "nesoft" :
/ # ./init
This is initramfs - init !!!
/ # ./nesoft
-/bin/sh: ./nesoft: not found
【3】, The two file have dirrerence below:
zhang#zhang-Virtual-Machine:~/src/qemu/third_patry/rootfs/busybox/rootfs$ file init
init: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, for GNU/Linux 3.2.0, BuildID[sha1]=08c7f187d91207660caa2db0101980a1f4b12716, notd
zhang#zhang-Virtual-Machine:~/src/qemu/third_patry/rootfs/busybox/rootfs$ file nesoft
nesoft: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 4.4.0, stripped
【4】, I have search ,so i think "LSB shared object" should run as executable file (I learn form https://unix.stackexchange.com/questions/472449/what-is-the-difference-between-lsb-executable-et-exec-and-lsb-shared-object )
BUT, why it still does not run ?
【END】
Has anyone meet this before, and know why ?
The main difference I see that second file is dynamically linked which means it requires library .so files to execute. I suppose it just that can't load the dependency.
Try running ldd (or export LD_TRACE_LOADED_OBJECTS=1 before running your binary since ldd may not be on busybox) to see which library is missing.

Matlab cannot find shared library on the LD_LIBRARY_PATH

I have some code that calls a Mex function. I compiled the Mex function and try to invoke the code, and get this error:
Invalid MEX-file '/v/filer4b/v41q001/evouga/projects/gptoolbox/mex/selfintersect.mexa64': libboost_thread.so.1.54.0: cannot open
shared object file: No such file or directory
But that library is definitely on the LD_LIBRARY_PATH:
>> getenv('LD_LIBRARY_PATH')
ans =
/lusr/opt/boost-1.54/lib:/v/filer4b/software/matlab-r2014a/sys/os/glnxa64:/v/filer4b/software/matlab-r2014a/bin/glnxa64:/v/filer4b/software/matlab-r2014a/extern/lib/glnxa64:/v/filer4b/software/matlab-r2014a/runtime/glnxa64:/v/filer4b/software/matlab-r2014a/sys/java/jre/glnxa64/jre/lib/amd64/native_threads:/v/filer4b/software/matlab-r2014a/sys/java/jre/glnxa64/jre/lib/amd64/server
And I know "No such file or directory" can sometimes mean "the file exists just fine, but is built for the wrong architecture, and for whatever reason we're going to print a blatant lie as the error message." But when I check
>> !file /lusr/opt/boost-1.54/lib/libboost_thread.so.1.54.0
/lusr/opt/boost-1.54/lib/libboost_thread.so.1.54.0: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=0x9ebc964acececa3632afe12b3526fe38f5b8c3eb, not stripped
it seems to be fine: a 64-bit library that matches the 64-bit .mexa64 file.
>> !file /v/filer4b/v41q001/evouga/projects/gptoolbox/mex/selfintersect.mexa64
/v/filer4b/v41q001/evouga/projects/gptoolbox/mex/selfintersect.mexa64: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, not stripped
What should I do next to try to figure out what's going on?

what does "-sh: executable_path:not found" mean

i am trying to run an executable in linux shell ( OpenELEC on raspberry pi )
OpenELEC:~ # /storage/fingi/usr/lib/autossh/autossh
-sh: /storage/fingi/usr/lib/autossh/autossh: not found
What does the "not found" in this case mean ?
If i try to do ldd:
OpenELEC:~ # ldd /storage/fingi/usr/lib/autossh/autossh
/usr/bin/ldd: eval: line 1: /storage/fingi/usr/lib/autossh/autossh: not found
And if i do file:
OpenELEC:~ # file /storage/fingi/usr/lib/autossh/autossh
/storage/fingi/usr/lib/autossh/autossh: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=599207c47d75b62ede5f214f9322ae2a18643eb7, stripped
The file type is in correct format . But it wont work adn wont give more descriptive error msg either.
Since openELEC is very restrictive, i had copied the autossh executable from a raspbmc installation . I have done it for several other executables as well ( screen , boost libraries etc ) and they work fine .
Can anyone suggest what might be the issue?
Edit 1:
as was suggested, this is the output of file command on an executable ( also copied from raspbmc ) that is working:
OpenELEC:~ # file /storage/fingi/usr/bin/screen
/storage/fingi/usr/bin/screen: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=5c58f047a25caa2c51a81d8285b4f314abc690e7, stripped
What does the "not found" in this case mean ?
This usually means that the executable cannot find one or more (shared) libraries to satisfy its external symbols.
This usually happens when no libraries are stored in the initramfs, or there is a shared library missing that the executable needs.
This can also happen if the executable is built with a C library that is incompatible with the runtime library, e.g. uClibc versus glibc/eglibc.
strings executable | less is the quickest way to see the required libraries and external symbols that the executable requires.
Or
Recompile your program and use static linking by specifying the -static option.
Check that the file has been set to executable permissions with ls -l if it hasn't change with chmod +x /storage/fingi/usr/lib/autossh/autossh

how to make sure a program or shared library is compiled with -g, in linux

I want to make sure my execute program is debug-able, what command can get the infomation.
I am a fan of using file to get information on executables and shared libraries.
The one key you are looking for is stripped in the description. If it is stripped it definitely does not have your debug symbols. Sadly, I am thinking a binary can still have no debug info but not be stripped.
$ file /usr/bin/file
/usr/bin/file: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, stripped
You can use objdump with the --debugging and --debugging-tags options

Is this a problem with my distro or the application?

I hope someone can help me with this :)
I am running Arch Linux and am trying to get a game to work (Penumbra Overture). I have downloaded the executable, checked the md5 and they match, installed it in a directory. However when I try to execute the file an error appears saying:
bash: ./penumbra.bin: No such file or directory
It does exist, I am in the right folder and it is set as executable:
-rwxr-xr-x 1 kumagoro users 6814000 Apr 15 2010 penumbra.bin
file penumbra.bin says:
penumbra.bin: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.2.5, stripped
ldd penumbra.bin says:
not a dynamic executable
So, is this a problem with my distro or the application?
Thanks
You are missing the interpreter for the binary. Check with
readelf -a penumbra.bin | grep -i program.interp
what it wants.

Resources