11

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 .
DrDirk
  • 1,937
  • 3
  • 25
  • 36

4 Answers4

23

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 :)

nsilent22
  • 2,763
  • 10
  • 14
  • The output is exactly as you said. How can I now definetly check if `/lib64/ld-linux-x86-64.so.2`exists? – DrDirk Jan 28 '16 at 21:36
  • 1
    Issue a `ls -l /lib64/ld-linux-x86-64.so.2`. Paste it's output here. – nsilent22 Jan 28 '16 at 21:37
  • ls output is: `ls: cannot access /lib64/ld-linux-x86-64.so.2: No such file or directory` so thx :) – DrDirk Jan 28 '16 at 21:38
  • Yes for one second I stopped thinking :D – DrDirk Jan 28 '16 at 21:39
  • 1
    I updated my answer how you can "override" the problem, if the binary isn't linked with exotic libraries. – nsilent22 Jan 28 '16 at 21:41
  • Thx for the additional answers. **sudo** I have no admin rights an therefore cannot use apt-get, **different linker** I tried this options but with no success: `find /lib* -name ld-linux\*` outputs: `/lib/ld-linux.so.2` and `/lib/i686/cmov/ld-linux.so.2` now I tried `/lib/ld-linux.so.2 wkhtmltopdf -H` with the output `wkhtmltopdf: error while loading shared libraries: wkhtmltopdf: cannot open shared object file: No such file or directory`, the same happend with the other linker. In general I think I cannot use wkhtmltopdf on this shared server ;) – DrDirk Jan 30 '16 at 16:48
  • @Knowledge: Are you sure this machine is 64bit? What `uname -m` outputs? – nsilent22 Jan 30 '16 at 16:51
  • `> uname -m` outputs : `x86_64`, so I guess I am running on a 64bit system? – DrDirk Feb 02 '16 at 09:44
  • @Knowledge: Looks like. So, if you don't have admin-rights you can try to manually download the package (e.g. from here: https://packages.debian.org/jessie/amd64/wkhtmltopdf/download), and then manually unpack it, and you'll get the binary. But it looks like it depends on lots of other libraries (Qt5 for example), so I think the game is not worth the candle. – nsilent22 Feb 02 '16 at 17:43
  • Well done. I had this problem when trying to run a RHEL executable on Ubuntu. You might mention this as a possible reason in your answer. – John McGehee Mar 25 '20 at 00:54
5

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)
Pablo Bianchi
  • 1,824
  • 1
  • 26
  • 30
2

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
vkersten
  • 131
  • 1
  • 5
-1

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.

Joshua Kaldon
  • 21
  • 6