I know this question has been asked a lot, but the problem remains fo me:
I have a 64bits ELF executable that I am trying to run on my Kali VM, but it keeps telling me that the file doesn't exist.
The solution most of the time for this problem is the difference of architecture, but my Kali is x86-64:
$ uname -m
x86_64
like the file (named '8') that I am trying to execute:
file 8
8: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.27, BuildID[sha1]=0xf3b096c69086131b091d1805894fde4fae0537a0, stripped
EDIT: Error:
$ chmod +x 8
$ ./8
bash: ./8: No such file or directory
EDIT 2 : lld:
linux-vdso.so.1 => (0x00007fffe37fe000)
libssl.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f680fac8000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f680f73c000)
libcrypto.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f680f343000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f680f13f000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f680ef28000)
/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f680fd49000)
I tried to install the 32 bits library to be sure, but it didn't solve anything neither. I also tried it on my Ubuntu, same issues.
Has anybody an idea on ho to run it ? Here is a link to it if some of you want to try on other architectures: https://www.dropbox.com/s/s3ucka4ufd00zmy/8?dl=0
bash: ./8: No such file or directory
This is caused by the file having an elf interpreter which is not installed on your system.
You can find out which elf interpreter your file is compiled with by running
readelf -l ./8 | grep interpreter
I am guessing that you have /lib/ld-linux-x86-64.so.2 compiled in, whereas the standard 64-bit elf interpreter is /lib64/ld-linux-x86-64.so.2.
The best fix is to correct the build script for your executable (it has something like -Wl,--dynamic-linker=/lib/ld-linux-x86-64.so.2 in it).
Alternatively, creating a symlink:
sudo ln -s /lib64/ld-linux-x86-64.so.2 /lib
will also fix the problem.
Related
I'm trying to get some binaries running on NixOS, and I ran into a weird situation when trying to get ldd to find libpython2.7.so.1.0 and other libs.
$ ldd lldb
./lldb: /nix/store/5rjfisjzz6vgwmgf7zx25yd9p6rfs0zy-ncurses-6.2-abi5-compat/lib/libtinfo.so.5: no version information available (required by ./lldb)
./lldb: /nix/store/5rjfisjzz6vgwmgf7zx25yd9p6rfs0zy-ncurses-6.2-abi5-compat/lib/libtinfo.so.5: no version information available (required by /nix/store/nn8pr7xzam0rz7fq95x9dpi087xazsnv-theos/share/theos/toolchain/linux/iphone/usr/bin/./../lib/liblldb.so.10git)
linux-vdso.so.1 (0x00007ffd57b80000)
libpthread.so.0 => /nix/store/z56jcx3j1gfyk4sv7g8iaan0ssbdkhz1-glibc-2.33-56/lib/libpthread.so.0 (0x00007f921e821000)
liblldb.so.10git => /nix/store/nn8pr7xzam0rz7fq95x9dpi087xazsnv-theos/share/theos/toolchain/linux/iphone/usr/bin/./../lib/liblldb.so.10git (0x00007f9215c3c000)
libz.so.1 => /nix/store/1l4r0r4ab3v3a3ppir4jwiah3icalk9d-zlib-1.2.11/lib/libz.so.1 (0x00007f9215c1f000)
librt.so.1 => /nix/store/z56jcx3j1gfyk4sv7g8iaan0ssbdkhz1-glibc-2.33-56/lib/librt.so.1 (0x00007f9215c12000)
libdl.so.2 => /nix/store/z56jcx3j1gfyk4sv7g8iaan0ssbdkhz1-glibc-2.33-56/lib/libdl.so.2 (0x00007f9215c0d000)
libtinfo.so.5 => /nix/store/5rjfisjzz6vgwmgf7zx25yd9p6rfs0zy-ncurses-6.2-abi5-compat/lib/libtinfo.so.5 (0x00007f9215ba7000)
libm.so.6 => /nix/store/z56jcx3j1gfyk4sv7g8iaan0ssbdkhz1-glibc-2.33-56/lib/libm.so.6 (0x00007f9215a66000)
libstdc++.so.6 => /nix/store/c9f15p1kwm0mw5p13wsnvd1ixrhbhb12-gcc-10.3.0-lib/lib/libstdc++.so.6 (0x00007f9215891000)
libgcc_s.so.1 => /nix/store/c9f15p1kwm0mw5p13wsnvd1ixrhbhb12-gcc-10.3.0-lib/lib/libgcc_s.so.1 (0x00007f9215875000)
libc.so.6 => /nix/store/z56jcx3j1gfyk4sv7g8iaan0ssbdkhz1-glibc-2.33-56/lib/libc.so.6 (0x00007f92156b0000)
/nix/store/z56jcx3j1gfyk4sv7g8iaan0ssbdkhz1-glibc-2.33-56/lib/ld-linux-x86-64.so.2 => /nix/store/z56jcx3j1gfyk4sv7g8iaan0ssbdkhz1-glibc-2.33-56/lib64/ld-linux-x86-64.so.2 (0x00007f921e843000)
libpython2.7.so.1.0 => not found
libncurses.so.5 => not found
libform.so.5 => not found
libpanel.so.5 => not found
libuuid.so.1 => not found
libedit.so.2 => not found
libxml2.so.2 => not found
There are quite a few missing, but let's focus on libpython2.7.so.1.0. When we check the RUNPATH of ld64,
$ readelf -d ld64 | rg RUNPATH
0x000000000000001d (RUNPATH) Library runpath: [/nix/store/c9f15p1kwm0mw5p13wsnvd1ixrhbhb12-gcc-10.3.0-lib/lib:/nix/store/z56jcx3j1gfyk4sv7g8iaan0ssbdkhz1-glibc-2.33-56/lib:/nix/store/xvyzi7cr0icnyavi5pm9rywjc4d8l7sx-libedit-20210714-3.1/lib:/nix/store/yxflij8cg4fgnzqmda91jx4d94jvkjf5-util-linux-2.37.2-lib/lib:/nix/store/370lxynzkmwrk8685jx9p2vgh7h0xp2h-libxml2-2.9.12/lib:/nix/store/5rjfisjzz6vgwmgf7zx25yd9p6rfs0zy-ncurses-6.2-abi5-compat/lib:/nix/store/nvx0l614cv661i5zz6w3j3y2w1xzppv1-python-2.7.18/lib:/nix/store/7344a20iqaja6i2qdz2xrgzy28rgnz5p-util-linux-2.37.2-lib/lib:/nix/store/1l4r0r4ab3v3a3ppir4jwiah3icalk9d-zlib-1.2.11/lib:$ORIGIN/../lib]
it contains /nix/store/nvx0l614cv661i5zz6w3j3y2w1xzppv1-python-2.7.18/lib, which has our desired lib,
$ file /nix/store/nvx0l614cv661i5zz6w3j3y2w1xzppv1-python-2.7.18/lib/libpython2.7.so.1.0
/nix/store/nvx0l614cv661i5zz6w3j3y2w1xzppv1-python-2.7.18/lib/libpython2.7.so.1.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped
I'm not sure how this is possible. The executable is also 64-bit, as we can see here:
$ file lldb
lldb: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /nix/store/z56jcx3j1gfyk4sv7g8iaan0ssbdkhz1-glibc-2.33-56/lib/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, not stripped
I'm not sure how this is possible.
There is a big difference between RUNPATH and RPATH: the former applies only to the binary itself (in this case, only to the lldb binary), the latter applies to the binary and all its dependencies.
Effectively using RUNPATH forces all binaries participating in the (dynamic) link to be linked correctly (to specify their own RUNPATH so that every one of their (recursive) dependencies is found).
What you observe is possible if:
lldb does not itself depend on libpython.2.7.so.1.0 and
one of lldbs dependencies does depend on on libpython.2.7.so.1.0 and
that dependency itself does not have a RUNPATH in which libpython.2.7.so.1.0 can be found.
You can verify that 1) is true with readelf -d ./lldb | grep libpython (I predict there will be no output).
If 1) is true, we know that 2 is true because libpython shows up in ldd output. You can find which of lldbs direct dependencies this is by going through them one by one (you can see them in the output from readelf -d lldb | grep NEEDED).
Once you found a dependency which needs libpython, you can confirm 3) by using readelf -d $direct_dependency | grep R.*PATH.
I have a container built from base image alpine:3.11
Now I have a binary my_bin that I copied into the running container. From within the running container I moved to /usr/local/bin and I confirmed that the binary is there with the right permissions. Eg
/ # ls -l /usr/local/bin/my_bin
-rwxr-xr-x 1 root root 55662376 Jun 12 18:52 /usr/local/bin/my_bin
But when I attempt to execute/run this binary I get the following:
/ # my_bin init
/bin/sh: my_bin: not found
This is also the case if I switch into /usr/local/bin/ and run via ./my_bin
also if I try using the full path
/# /usr/local/bin/my_bin init
/bin/sh: /usr/local/bin/my_bin: not found
Why am I seeing this behavior? and how do I get to be able to execute the binary?
EDIT 1
I installed file and I can also confirm that the binary is copied and is an executable
file /usr/local/bin/my_bin
/usr/local/bin/my_bin: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=b36f0aad307c3229850d8db8c52e00033eae900c, for GNU/Linux 3.2.0, not stripped
Maybe this gives some extra clues?
Edit 2
As suggested by #BMitch in the answer I also ran ldd and here is the output
# ldd /usr/local/bin/my_bin
/lib64/ld-linux-x86-64.so.2 (0x7f91a79f3000)
libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7f91a79f3000)
libdl.so.2 => /lib64/ld-linux-x86-64.so.2 (0x7f91a79f3000)
libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f91a79f3000)
** Edit 3 **
Based on the output of ldd and more googling, I find that running apk add libc6-compat installed the missing libraries and I could then run the binary.
For a binary, this most likely indicates a missing dynamic library. You can run ldd /usr/local/bin/my_bin to see all the libraries that binary uses. With alpine, the most common library to be missing from an externally compiled program is libc. Alpine is built with musl instead of libc, and therefore you'll want to compile programs specifically for Alpine.
For others that may encounter this error in docker containers, I cover various issues in my faq presentation and other questions on the site.
/ # my_bin init
/bin/sh: my_bin: not found
When you execute above line it says file which you are trying to execute can't be found, my_bin is the file in your case.
Check if file is copied properly and with the same name or you might be trying to execute file from different location.
e.g. Try /usr/local/bin/my_bin init if you are not doing cd /usr/local/bin after ls -l /usr/local/bin/my_bin command.
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
Short question:
How does llvm-ld locate libstdc++?
Details:
I am getting the following error message:
llvm-ld: error: Cannot find library 'stdc++'
while running llvm-ld. I am trying to understand how llvm-ld searches for libstdc++.
I am setting up a new system and following compilation steps that work on a different system. Eventually I noticed a difference with the LD_LIBRARY_PATH that was set in my .bashrc on the old system that included a large number of directories including for Cadence and other miscellaneous software. I don't want to use the LD_LIBRARY_PATH, I want to be able to link against libstdc++ by supplying the appropriate command line parameters to llvm-ld.
The command I am running is:
llvm-ld -disable-internalize -native -o foo foo.bc4 -L/usr/lib/x86_64-linux-gnu -lpthread -lrt -lstdc++ -lm -v
which results in the following output:
Linking bitcode file 'foo.bc4'
Linked in file 'foo.bc4'
Linking archive file '/usr/lib/x86_64-linux-gnu/libpthread.a'
Linking archive file '/usr/lib/x86_64-linux-gnu/librt.a'
llvm-ld: error: Cannot find library 'stdc++'
However running ls -l /usr/lib/x86_64-linux-gnu/libstdc++* results in:
lrwxrwxrwx 1 root root 19 Apr 15 16:34 /usr/lib/x86_64-linux-gnu/libstdc++.so.6 -> libstdc++.so.6.0.16
-rw-r--r-- 1 root root 962656 Apr 15 16:36 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16
So I don't understand why llvm-ld is not finding this file? Especially since when I compile with with the LD_LIBRARY_PATH set and then run ldd on the resulting executable I get the following output:
linux-vdso.so.1 => (0x00007ffff7ffe000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ffff7dc1000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007ffff7ac0000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ffff77c6000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ffff75b0000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ffff71f0000)
/lib64/ld-linux-x86-64.so.2 (0x0000555555554000)
Which seems to indicate that the version of libstdc++ that I want is /usr/lib/x86_64-linux-gnu/libstdc++.so.6 but I can't figure out why llvm-ld is not locating it with the search path -L/usr/lib/x86_64-linux-gnu.
For reference: uname -a results in: Linux FOO 3.2.0-30-generic #48-Ubuntu SMP Fri Aug 24 16:52:48 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
And llvm-ld --version:
LLVM (http://llvm.org/):
LLVM version 3.1svn
Optimized build.
Built Sep 14 2012 (13:22:38).
Default target: x86_64-unknown-linux-gnu
Host CPU: core2
It looks like llvm-ld isn't looking for .so.#. According to the man page:
When looking for a library specified with the -l option, llvm-ld first attempts to load a file with that name from the current directory. If that fails, it looks for liblibrary.bc, liblibrary.a, or liblibrary.shared library extension, in that order, in each directory added to the library search path with the -L option. These directories are searched in the order they are specified. If the library cannot
be located, then llvm-ld looks in the directory specified by the LLVM_LIB_SEARCH_PATH environment variable. If it does not find a library there, it fails.
You can make this work by creating a symlink /usr/lib/x86_64-linux-gnu/libstdc++.so -> libstdc++.so.6.
I usually link with clang directly, since it understands searching for C++ library things better.
I installed Qt4 in my local home in a Ubuntu system and the Qt4 libraries are in ~/lib. I have another program (hawkeye for genome assembly) dependent on Qt4 however when I run that it gives the error message:
error while loading share libraries: libQt3Support.so.4: cannot open shared object file: No such file or directory
I checked ~/lib and all the Qt libs are there. Do I need to add the path ~/lib to anywhere?
A good way to debug problems like this is to take a look at the ldd output. For example:
$ ldd yourProg
linux-gate.so.1 => (0xffffe000)
libc.so.6 => /lib/libc.so.6 (0xb7e3d000)
libQtGui.so => /usr/lib/libQtGui.so.4.7.0 (0xb7f7f000)
libQt3Support.so => (not found)
...
The above output will tell you if it's picking up your copy of Qt or the system version. Then you can set LD_LIBRARY_PATH or edit ld.so.conf and rerun ldconfig. For example:
$ export LD_LIBRARY_PATH=/path/to/your/qt
$ ldd yourProg
Or (as root):
# echo "/path/to/your/qt" >> /etc/ld.so.conf
# ldconfig
$ ldd yourProg