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


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


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


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

real    0m0.002s
user    0m0.000s
sys     0m0.000s
  • 1
    What about LD_DEBUG=all /lib/ld-lsb.so.3 ./zls? – Stéphane Chazelas May 20 '13 at 19:20
  • 1
    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

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 9 '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 1 '18 at 16:35

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.