"No such file or directory" on an executable, yet file exists and ldd reports all libraries present

Question

So by any other command the executable file exists, yet when I try to execute it, it claims it is not there.

It is not a special character in the name because I renamed it though a "cat". And it seems to be a binary for the correct architecture... "seems", I guess the question is, what else throws tat error message BESIDES... the file not being there, because it obviously IS!

ldd xls

    linux-gate.so.1 =>  (0xb77bc000)
    libQtGui.so.4 => /usr/lib/i386-linux-gnu/libQtGui.so.4 (0xb6cc2000)
    libpng12.so.0 => /lib/i386-linux-gnu/libpng12.so.0 (0xb6c98000)
    libSM.so.6 => /usr/lib/i386-linux-gnu/libSM.so.6 (0xb6c8f000)
    libICE.so.6 => /usr/lib/i386-linux-gnu/libICE.so.6 (0xb6c76000)
    libXrender.so.1 => /usr/lib/i386-linux-gnu/libXrender.so.1 (0xb6c6d000)
    libfreetype.so.6 => /usr/lib/i386-linux-gnu/libfreetype.so.6 (0xb6bd1000)
    libfontconfig.so.1 => /usr/lib/i386-linux-gnu/libfontconfig.so.1 (0xb6b9b000)
    libXext.so.6 => /usr/lib/i386-linux-gnu/libXext.so.6 (0xb6b88000)
    libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0xb6a50000)
    libm.so.6 => /lib/i386-linux-gnu/i686/cmov/libm.so.6 (0xb6a2a000)
    libQtSql.so.4 => /usr/lib/i386-linux-gnu/libQtSql.so.4 (0xb69ea000)
    libQtCore.so.4 => /usr/lib/i386-linux-gnu/libQtCore.so.4 (0xb6704000)
    libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb66ea000)
    libgthread-2.0.so.0 => /usr/lib/i386-linux-gnu/libgthread-2.0.so.0 (0xb66e7000)
    libglib-2.0.so.0 => /lib/i386-linux-gnu/libglib-2.0.so.0 (0xb65ea000)
    libgobject-2.0.so.0 => /usr/lib/i386-linux-gnu/libgobject-2.0.so.0 (0xb6598000)
    librt.so.1 => /lib/i386-linux-gnu/i686/cmov/librt.so.1 (0xb658f000)
    libpthread.so.0 => /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 (0xb6575000)
    libdl.so.2 => /lib/i386-linux-gnu/i686/cmov/libdl.so.2 (0xb6571000)
    libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb6485000)
    libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb6468000)
    libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xb6305000)
    libaudio.so.2 => /usr/lib/i386-linux-gnu/libaudio.so.2 (0xb62ea000)
    libuuid.so.1 => /lib/i386-linux-gnu/libuuid.so.1 (0xb62e4000)
    libexpat.so.1 => /lib/i386-linux-gnu/libexpat.so.1 (0xb62ba000)
    libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0xb6297000)
    /lib/ld-lsb.so.3 => /lib/ld-linux.so.2 (0xb77bd000)
    libpcre.so.3 => /lib/i386-linux-gnu/libpcre.so.3 (0xb6258000)
    libffi.so.5 => /usr/lib/i386-linux-gnu/libffi.so.5 (0xb624f000)
    libXt.so.6 => /usr/lib/i386-linux-gnu/libXt.so.6 (0xb61f1000)
    libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0xb61ee000)
    libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6 (0xb61e8000)

uname -m (Also, my distribution is Debian wheezy.)

i686

file xls

xls: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), 
     dynamically linked (uses shared libs), for GNU/Linux 2.6.15,
     BuildID[sha1]=0xa9786f61b371a683ae4306792f95e0636c288883, not stripped

ls -ld xls

-rwxr-xr-x 1 root root 4634064 May 20 14:35 xls

cat

root@pc170:# cat xls > zls
root@pc170:# ./zls
-su: ./zls: Permission denied
root@pc170:# chmod +x zls
root@pc170:# ./zls
-su: ./zls: No such file or directory

time

root@pc170:# time ./zls
-su: ./zls: No such file or directory

real    0m0.002s
user    0m0.000s
sys     0m0.000s

One thing about this: it says `"su: "` which makes it seem like you're executing a `system()` or something from inside the program and it's saying that after it does the `su` it can't find the executable in the directory it ends up in. What happens if you copy or symlink it to `/bin` or something? — Bratchley, May 20 '13 at 19:23
Let's try `objdump -j .interp -s ./zls`. I suspect that will list the file that doesn't exist. — derobert, May 20 '13 at 21:12

score 24 · Answer 1 · edited Apr 13 '17 at 12:36

This does look like a missing loader. Short story: the dynamic loader expected by the program is missing, and the error messages are misleading in this case. Since I don't think I've discussed that before, let me explain the relevant part of the output of ldd. Most of it constists of lines of the form library_soname => /path/to/library_file.

/lib/ld-lsb.so.3 => /lib/ld-linux.so.2 (0xb77bd000)

Amongst the libraries, we see something that isn't a shared library: it's the program that loads the shared libraries. The program is requesting /lib/ld-lsb.so.3, but the kernel doesn't find it, so it reports “No such file or directory”. Yet ldd does find the loader, because ldd is a wrapper script that calls a hard-coded loader in a special environment, and the loader always reports its own path no matter what loader path the program has expected.

You have /lib/ld-linux.so.2 on your system, which is the de facto standard location for the ELF loader on x86_32 Linux systems. The program requires /lib/ld-lsb.so.3, which is the de jure standard location.

Install your distribution's minimal LSB support, for example the lsb-core package on Debian. If your distribution doesn't have that (most do), create a symbolic link /lib/ld-lsb.so.3 -> ld-linux.so.2. In desperation you can call the loader explicitly: /lib/ld-linux.so.2 ./xls.

Indeed, the loader is what that objdump line would have printed out. I forgot it was actually in the `ldd` output. Good catch! — derobert, May 22 '13 at 16:53
This is exactly the problem I saw, with the misleading error message. One issue is that 'ldd' won't run if the dynamic loader isn't present because it's (on centos at least) a shell script. — dajobe, Dec 09 '15 at 21:47
Thank you for this most helpful post among a sea of posts that talk about missing 32-bit libs on a 64-bit system. — Michael Burr, Aug 31 '16 at 20:24
`readelf -a zls | grep "Requesting program interpreter"` will print the loader. — Kevin Smyth, Feb 01 '18 at 16:35

"No such file or directory" on an executable, yet file exists and ldd reports all libraries present

1 Answers1

Linked

Related