Bash: No such file or directory? - linux

Question

I try to use an executable script (wkhtmltopdf) on a Linux shared webserver (Debian, 64bit). I am pretty sure that I compiled everything correct, but whenever I want to execute the file I get as an response :
> ./wkhtmltopdf -H
-bash: ./wkhtmltopdf: No such file or directory
To be sure that the file is there, here the ls output :
> ls
wkhtmltoimage wkhtmltopdf
Furthermore I tested the file command on it, which outputs the following :
> file wkhtmltopdf
wkhtmltopdf: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped
My question is now :
Why does bash tells me that there is no 'file or directory', when there obviously is one?
My first guess would be that the shared server does not allow to execute binary files? But shouldn't it then be a problem of permissions, with a different bash output?
Edit :
> id
uid=2725674(p8907906) gid=600(ftpusers) groups=600(ftpusers)
> ls -l wkhtmltopdf
-rwxrwxrwx 1 p8907906 ftpusers 39745960 Jan 20 09:33 wkhtmltopdf
> ls -ld
drwx---r-x 2 p8907906 ftpusers 44 Jan 28 21:02 .

Answer 1

I bet you miss dynamic linker. Just do a
readelf --all ./wkhtmltopdf | grep interpreter
You should get an output like this:
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
There are high chances that you system lacks the interpreter (/lib64/ld-linux-x86-64.so.2 in the example). In this case bash would yell No such file or directory, just like when the binary itself is missing.
You can try to use a different linker. Sometime you can succeed. Just do a:
/path/to/the/linker /path/to/your/executable
This command:
find /lib* -name ld-linux\*
will help you find the linkers on your system. Or you can do the readelf command on some command that does run. It will show you correct, working linker.
OR, since you are running Debian system, just do a
sudo apt-get install wkhtmltopdf
to install native version of the tool :)

Answer 2

In my case
$ readelf --all ./wkhtmltopdf | grep interpreter # readelf: Displays information about ELF files.
[Requesting program interpreter: /lib/ld-linux.so.2]
On a machine where the executable was working:
$ ls -lah /lib/ld-linux.so.2
lrwxrwxrwx 1 root root 25 Apr 16 2018 /lib/ld-linux.so.2 -> i386-linux-gnu/ld-2.27.so
$ dpkg -S /lib/ld-linux.so.2 # -S, --search filename-search-pattern: Search for a filename from installed packages.
libc6:i386: /lib/ld-linux.so.2
So to fix the problem (reference)
sudo dpkg --add-architecture i386
sudo apt update
sudo apt install libc6:i386 # GNU C Library: Shared libraries (from apt show)

Answer 3

Missing the linker was my case as well. I could fix it with the help of nsilent22 answer like this:
readelf --all /usr/local/myprogram | grep interpreter
[Requesting program interpreter: /lib64/ld-lsb-x86-64.so.3]
But that linker did not exist anymore.
The old situation in /lib64 was:
ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.31.so
ld-linux-x86-64.so.3 -> ld-linux-x86-64.so.2
So it turned out this was just a symlink to the systems' linker.
Moving over to /lib64 , which itself is a symlink to usr/lib64 and creating a symlink over there did not work. I assume that there are to many symbolic link levels after Debian moved everything into /usr
However creating a 'direct' symlink
ln -s /usr/lib64/ld-linux-x86-64.so.2 /lib64/ld-lsb-x86-64.so.3
did the job; /usr/lib64 now shows:
ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.31.so
ld-lsb-x86-64.so.3 -> /usr/lib64/ld-linux-x86-64.so.2

Answer 4

I ran into this issue on my raspberry pi 4 running aarch64 alpine 3.13. Using the answer provided by #vkersten, I was able to determine that I was missing /lib/ld-linux-aarch64.so.1.
I resolved this by installing gcompat with apk add gcompat.