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?
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've installed ccx (Calculix solver programm) to solve a physical problem. The preprocessor cgx works fine, but when I run ccx with an .inp file (abaqus) in terminal, there comes an error:
ccx: symbol lookup error: ccx: undefined symbol: _gfortran_internal_malloc
when I only run ccx without a flag or .inp file, the result is:
Usage: CalculiX.exe -i jobname
I have libgfortran3 installed on my ubuntu 14.04 computer (64 bit: x86_64) and link the "libgfortran.so.3.0.0" file in "/usr/lib/x86_64/" with a created reference object file "libgfortran.so.2" (calculix needs that file 'cause the application runs on 32 bit). Without that reference file ccx doesn't work completely and thats why I had to link it. I use Calculix 2.8p2.
If your application is 32 bit, it needs 32 bit libraries to work. What you've done is install 64 bit libraries and then symlinked them to where the 32 bit library should be. This satisfies that the library "exists" but it will be unusable for the 32 bit program.
My library locations will differ from yours, but observe that they are different:
64 bit libgfortran.so
$ file /usr/lib64/gcc/x86_64-pc-linux-gnu/5.2.0/libgfortran.so.3.0.0
/usr/lib64/gcc/x86_64-pc-linux-gnu/5.2.0/libgfortran.so.3.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped
32 bit libgfortran.so
$ file /usr/lib64/gcc/x86_64-pc-linux-gnu/5.2.0/32/libgfortran.so.3.0.0
/usr/lib64/gcc/x86_64-pc-linux-gnu/5.2.0/32/libgfortran.so.3.0.0: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped
Secondly, if your program needs libgfortran.so.2, then symlinking a version of libfortran.so.3 in its place will not work. The change in library version number is a good signal that they are not compatible and not interchangeable. You will need to find a package that provides the older library for i386 architecture. This might mean installing a package from an older version of ubuntu.
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
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