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
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.


  • 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.
  • 2
    Probably better asked on ubuntu.stackexchange.com – Oded Sep 28 '10 at 20:14
  • 1
    Try ls -l ./tagger – Mark Ransom Sep 28 '10 at 20:15
  • do ldd ./tagger – nos Sep 28 '10 at 20:24
  • @MarkRansom ls -ld ./tagger return -rwxr-xr-x 1 user user 28938 2010-09-28 15:56 ./tagger – Craig Gidney Sep 28 '10 at 20:58
  • 1
    @Strilanc Either 'tagger' is a symlink to something that doesn't exist, Or you've created that executable on an old system, and your other system can no longer identify that format, or the exe is a statically linked program intended for another architecture. Run `` ls -l ./tagger` and file ./tagger to learn more about the file. – nos Sep 28 '10 at 21:28

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.


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

  • This is great advice. If you're using Ubuntu, you can do a package content search at packages.ubuntu.com to find out the package and architecture which contains the required file, and then install the package. In my case, I needed the 32-bit ld-linux which I installed with sudo apt-get install libc6:i386 – Tom Shaw Jul 31 '14 at 8:09

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
  • The command "pico tagger" opens up a file (looks like binary data), so it can't be a stale soft link. Edited the question to reflect this. – Craig Gidney Sep 28 '10 at 20:56
  • 2
    @Strilanc, the file command is better for this than a text editor. In the above example the output of file fff would have been fff: broken symbolic link to 'ld' – jonescb Sep 28 '10 at 21:03
  • file tagger gives "tagger: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.0.0, not stripped". This is surprising, because ldd says it is not a dynamic executable. At this point I believe it's a mismatched-architecture thing and I should recompile on the target machine. – Craig Gidney Sep 28 '10 at 21:36
  • 4
    ldd says it's not an dynamic linked executable because the executable is compiled on a very old machine, using a different dynamic linker than the system you're trying to run it on. i.e. the real error is /lib/ld-linux.so.1 (or some other version you don't have) cannot be found. – nos Sep 28 '10 at 21:59
  • @Strilanc: If you are on an x86_64 machine, then that's the answer. It's a rather misleading bit of output... – Daenyth Sep 29 '10 at 17:43

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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.