Why would an executable say it doesn't exist when I try to run it?

Question

I have a compiled program, a tagger to identify parts of text, which claims it does not exist.

When I attempt to run it via the command line, I get this:

user@place:/home/user/explicitRedactedPath$ ls tagger
tagger
user@place:/home/user/explicitRedactedPath$ ./tagger arg and other args
-bash: ./tagger: No such file or directory

This executable has to be called by a generated script, which is how I ran into this issue. What are the reasons this error could show up? I'm out of ideas on how to fix it.

Notes:

• OS is Ubuntu
• The executable was copied from another machine
• The file does have execution privileges (it gives a proper not-allowed message without them)
• I've tried copying the file to a different location (same problem)
• I've tried replacing the file with a fresh copy (same problem)
• The file does exist. Opening it with pico shows a file with binary data.

Answer 1

The program was compiled for an incompatible architecture, resulting in a non-executable program. The error message stating "does not exist" instead of "invalid executable" is just a very misleading message.

Recompiling it on the target machine fixed the problem.

Answer 2

I had a problem very similar to the OP (./lfm: Command not found. when I was looking right at it), and some of the answers here helped me figure out how to run my executable on a different system without recompiling. Here's how I would advise my past self (if I thought past-me was smart enough to listen for a change):

1) Verify that the file isn't a broken link, that it has executable permissions, and that you aren't trying to run a 64-bit executable on a 32-bit OS (for me, file lfm returned lfm: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped so it is 64-bit; check the output of uname -a for x86_64 in it, to verify the OS is 64-bit, too; i386 or i686 means 32-bit) (substitute your program name for lfm in these examples, of course).

2) ldd lfm returned the odd not a dynamic executable message (rather than printing the shared library dependencies), so try readelf -l ./lfm | grep ld-linux to find out where the executable expects to find ld-linux, which is the linux loader for dynamically linked libraries (in my case, this returned [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]).

3) Checking the directory indicated by the previous command shows that the indicated ld-linux file is not there; copy it over from the machine the program was originally compiled on (or a similar system, if necessary) to that directory.

4) Try running the original program again. (Worked for me.) Also, ldd ./lfm should work now (but you can always use readelf -d ./lfm to see what libraries are needed, and then verify that they're available.)

Answer 3

Probably tagger is a soft-link and the target of the link isn't there. Reproduce like this:

$ cp /usr/bin/ld .
$ ln -s ld fff
$ rm ld
$ ./fff
zsh: no such file or directory: ./fff

Answer 4

You may be missing shared libraries.

Do 'ldd tagger' to see a list of required libraries.

% ldd /bin/zsh                                                                                   
libcap.so.2 => /lib/libcap.so.2 (0x00007f50ce8db000)
libdl.so.2 => /lib/libdl.so.2 (0x00007f50ce6d7000)
libm.so.6 => /lib/libm.so.6 (0x00007f50ce201000)
libc.so.6 => /lib/libc.so.6 (0x00007f50cdea0000)
libattr.so.1 => /lib/libattr.so.1 (0x00007f50cdc9b000)
/lib64/ld-linux-x86-64.so.2 (0x00007f50ceaf8000)

If one of them is missing it will not have a path next to it.

Answer 5

If you can't recompile, you might consider using statifier to map a dynamic executable into a statically linked one. Note, I haven't personally tried it.