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
Related
【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.
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.
I was given a "binary" file on linux and a seperate file for windows for a particular task. The programs is an exe on windows. A linux version of the file has the same function on linux as it had windows, too.
However, I've failed to be able to execute this. I tried (on the terminal) to execute it by just the file name, ./[filename], and even tried chmod +x [filename] and then tried the second way.
For everything... I get the result: "Command not found". (The file is definitely there, by the way).
What am I supposed to do? The file command on it yields:
ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=e805f746e65c09cc8b0c037d8a8c27ee0a6a051c
My guess is that this is 32 bit compile on a 64 bit system. I cross compiled a small c file into a binary using the -m32 option on gcc. This also needed a few extra packages. The resulting a.out looks like this.
% file a.out
a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=be02470c8337b96e7deaaff323bc53865991c3ab, not stripped
Compare this to a native system binary
% file /bin/ls
/bin/ls: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=a0823e17cafbe5b2296346216445566840fdfd88, stripped
Running the a.out shows me this.
% ./a.out
zsh: no such file or directory: ./a.out
The specific "Command not found" message is something, I think, bash prints. I use zsh myself.
To get this to work, you can install the multilib packages. I didn't narrow it down to the exact package but installing gcc-multilib on Debian pulls in everything you need. After installing that, here's what I get.
% ./a.out
3.140523
(the program is supposed to estimate the value of PI).
Note: I actually needed to install gcc-multilib just to compile the file. I then uninstalled the packages to mimic a 64 bit system that doesn't have the 32 bit runtime libraries that the thing needs.
does the a.out have executable permission ?
check with ls -la cmd and if does no then add the permission using chmod a+x a.out an d then try executing
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?
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