Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.
share|improve this question

migrated from stackoverflow.com Sep 30 '10 at 0:49

This question came from our site for professional and enthusiast programmers.

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
up vote 5 down vote accepted

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.

share|improve this answer

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

share|improve this answer
    
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
share|improve this answer
    
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.

share|improve this answer

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.

share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .