«Aucun fichier ou répertoire de ce type» sur un exécutable, mais le fichier existe et ldd signale toutes les bibliothèques présentes

Donc, par toute autre commande, le fichier exécutable existe, mais quand j'essaye de l'exécuter, il prétend qu'il n'est pas là.

Ce n'est pas un caractère spécial dans le nom car je l'ai renommé par "chat". Et il semble que ce soit un binaire pour l'architecture correcte ... "semble", je suppose que la question est, quoi d'autre jette ce message d'erreur à côté ... le fichier n'est pas là, car il l'est évidemment!

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 (De plus, ma distribution est Debian Wheezy.)

i686

fichier 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

chat

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

temps

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

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

Cela ressemble à un chargeur manquant . Petite histoire: le chargeur dynamique attendu par le programme est manquant, et les messages d'erreur sont trompeurs dans ce cas. Comme je ne pense pas avoir déjà discuté de cela auparavant, permettez-moi d'expliquer la partie pertinente de la sortie de ldd. La majeure partie est constituée de lignes du formulaire library_soname => /path/to/library_file.

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

Parmi les bibliothèques, nous voyons quelque chose qui n'est pas une bibliothèque partagée: c'est le programme qui charge les bibliothèques partagées. Le programme demande /lib/ld-lsb.so.3, mais le noyau ne le trouve pas, donc il signale «Aucun fichier ou répertoire de ce type». Pourtant, lddil trouve le chargeur, car il ldds'agit d'un script wrapper qui appelle un chargeur codé en dur dans un environnement spécial, et le chargeur signale toujours son propre chemin, quel que soit le chemin du chargeur auquel le programme s'attendait.

Vous avez /lib/ld-linux.so.2sur votre système, qui est l' emplacement standard de facto pour le chargeur ELF sur les systèmes Linux x86_32. Le programme requiert /lib/ld-lsb.so.3, qui est l' emplacement standard de jure .

Installez le support LSB minimal de votre distribution, par exemple le lsb-corepaquet sur Debian. Si votre distribution n'en a pas (la plupart en ont), créez un lien symbolique /lib/ld-lsb.so.3 -> ld-linux.so.2. En désespoir de cause , vous pouvez appeler le chargeur explicitement: /lib/ld-linux.so.2 ./xls.