"Nessun file o directory" su un file eseguibile, tuttavia esiste un file e ldd riporta tutte le librerie presenti

Quindi, con qualsiasi altro comando, esiste il file eseguibile, ma quando provo ad eseguirlo, afferma che non c'è.

Non è un personaggio speciale nel nome perché l'ho rinominato attraverso un "gatto". E sembra essere un binario per l'architettura corretta ... "sembra", suppongo che la domanda sia: cos'altro genera il messaggio di errore BESIDES ... il file non è lì, perché ovviamente È!

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 (Inoltre, la mia distribuzione è 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

gatto

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

tempo

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

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

linux executable

— sottovento
fonte

Che dire LD_DEBUG=all /lib/ld-lsb.so.3 ./zls?

— Stéphane Chazelas,

Una cosa a riguardo: dice "su: "che sembra che tu stia eseguendo uno system()o qualcosa dall'interno del programma e sta dicendo che dopo che non suriesce a trovare l'eseguibile nella directory in cui finisce. Cosa succede se copiarlo o collegarlo a /binqualcosa o qualcosa del genere?

— Bratchley,

Prova di Let objdump -j .interp -s ./zls. Sospetto che elencherà il file che non esiste.

— derobert,

Sembra un caricatore mancante . Breve storia: manca il caricatore dinamico previsto dal programma e in questo caso i messaggi di errore sono fuorvianti. Dal momento che non credo di averne discusso prima, lasciami spiegare la parte rilevante dell'output di ldd. La maggior parte consiste di linee della forma library_soname => /path/to/library_file.

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

Tra le librerie vediamo qualcosa che non è una libreria condivisa: è il programma che carica le librerie condivise. Il programma richiede /lib/ld-lsb.so.3, ma il kernel non lo trova, quindi riporta "Nessun file o directory". Tuttavia lddtrova il caricatore, perché lddè uno script wrapper che chiama un caricatore hardcoded in un ambiente speciale e il caricatore riporta sempre il proprio percorso, indipendentemente dal percorso del caricatore previsto.

Hai /lib/ld-linux.so.2sul tuo sistema, che è di fatto la posizione standard per il caricatore ELF su sistemi Linux x86_32. Il programma richiede /lib/ld-lsb.so.3, che è la posizione standard de jure .

Installa il supporto minimo LSB della tua distribuzione, ad esempio il lsb-corepacchetto su Debian. Se la tua distribuzione non lo possiede (molti lo fanno), crea un link simbolico /lib/ld-lsb.so.3 -> ld-linux.so.2. In preda alla disperazione si può chiamare il caricatore in modo esplicito: /lib/ld-linux.so.2 ./xls.

— Gilles 'SO- smetti di essere malvagio'
fonte

In effetti, il caricatore è ciò che quella linea objdump avrebbe stampato. Ho dimenticato che in realtà era lddnell'output. Buona pesca!

— derobert,

Questo è esattamente il problema che ho visto, con il messaggio di errore fuorviante. Un problema è che 'ldd' non funzionerà se il caricatore dinamico non è presente perché è (almeno su centos) uno script di shell.

— dajobe,

Grazie per questo post molto utile tra una serie di post che parlano di librerie a 32 bit mancanti su un sistema a 64 bit.

— Michael Burr,

readelf -a zls | grep "Requesting program interpreter"stamperà il caricatore.

— Kevin Smyth,