"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

• Stéphane Chazelas: What about LD_DEBUG=all /lib/ld-lsb.so.3 ./zls?
• Bratchley: 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?
• derobert: Let's try objdump -j .interp -s ./zls. I suspect that will list the file that doesn't exist.

Answer 1

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.

• derobert: Indeed, the loader is what that objdump line would have printed out. I forgot it was actually in the ldd output. Good catch!
• dajobe: 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.
• Michael Burr: Thank you for this most helpful post among a sea of posts that talk about missing 32-bit libs on a 64-bit system.
• Kevin Smyth: readelf -a zls | grep "Requesting program interpreter" will print the loader.