"No existe tal archivo o directorio" en un ejecutable, sin embargo, el archivo existe y ldd informa de todas las bibliotecas presentes

Entonces, por cualquier otro comando, el archivo ejecutable existe, pero cuando trato de ejecutarlo, afirma que no está allí.

No es un carácter especial en el nombre porque lo renombré a través de un "gato". Y parece ser un binario para la arquitectura correcta ... "parece", supongo que la pregunta es, ¿qué más arroja un mensaje de error ADEMÁS ... el archivo no está allí, porque obviamente ES!

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 (Además, mi distribución es Debian wheezy).

i686

archivo 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

gato

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

hora

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

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

linux executable

— Sotavento
fuente

¿Qué hay de LD_DEBUG=all /lib/ld-lsb.so.3 ./zls?

— Stéphane Chazelas

Una cosa acerca de esto: dice lo "su: "que hace que parezca que estás ejecutando un system()o algo desde el interior del programa y dice que después de hacerlo no supuede encontrar el ejecutable en el directorio en el que termina. ¿Qué sucede si copiar o vincularlo /bino algo así?

— Bratchley

Try de Let objdump -j .interp -s ./zls. Sospecho que enumerará el archivo que no existe.

— derobert

Esto parece un cargador perdido . Breve historia: falta el cargador dinámico esperado por el programa, y los mensajes de error son engañosos en este caso. Como no creo haber discutido eso antes, permítanme explicar la parte relevante de la salida de ldd. La mayor parte consiste en líneas de la forma library_soname => /path/to/library_file.

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

Entre las bibliotecas, vemos algo que no es una biblioteca compartida: es el programa que carga las bibliotecas compartidas. El programa está solicitando /lib/ld-lsb.so.3, pero el núcleo no lo encuentra, por lo que informa "No existe tal archivo o directorio". Sin embargo ldd, encuentra el cargador, porque lddes un script de envoltura que llama a un cargador codificado en un entorno especial, y el cargador siempre informa su propia ruta, sin importar qué ruta de cargador haya esperado el programa.

Tiene /lib/ld-linux.so.2en su sistema, que es la ubicación estándar de facto para el cargador ELF en sistemas Linux x86_32. El programa requiere /lib/ld-lsb.so.3, que es la ubicación estándar de jure .

Instale el soporte LSB mínimo de su distribución, por ejemplo, el lsb-corepaquete en Debian. Si su distribución no tiene eso (la mayoría sí), cree un enlace simbólico /lib/ld-lsb.so.3 -> ld-linux.so.2. En su desesperación, se puede llamar al cargador de forma explícita: /lib/ld-linux.so.2 ./xls.

— Gilles 'SO- deja de ser malvado'
fuente

De hecho, el cargador es lo que esa línea objdump habría impreso. Olvidé que en realidad estaba en la lddsalida. ¡Buena atrapada!

— derobert

Este es exactamente el problema que vi, con el mensaje de error engañoso. Un problema es que 'ldd' no se ejecutará si el cargador dinámico no está presente porque es (al menos en centos) un script de shell.

— dajobe

Gracias por esta publicación tan útil entre un mar de publicaciones que hablan sobre la falta de bibliotecas de 32 bits en un sistema de 64 bits.

— Michael Burr

readelf -a zls | grep "Requesting program interpreter"imprimirá el cargador.

— Kevin Smyth