ldd mi dice che la mia app "non è un eseguibile dinamico"

17

Ho un'applicazione a 32 bit (chiamata uclsyn) che ho ricevuto da un professore di astronomia. Sono riuscito a farlo funzionare su CentOS un anno fa, ma ora quando sto configurando una nuova VM CentOS, non funzionerà e non riesco a capire perché. Continua a tornare con "Killed".

Questo è lo scambio sulla riga di comando:

$ ./uclsyn_linux
Killed

$ ldd ./uclsyn_linux
not a dynamic executable

$ file ./uclsyn_linux
uclsyn_linux: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped

Sulla macchina che viene eseguita, "ldd ./uclsyn_linux" restituisce un intero elenco di dipendenze. Ho trovato i pacchetti che forniscono queste librerie condivise e sembrano tutti installati.

Pacchetti richiesti

libSM-1.1.0-7.1.el6.i686
libX11-1.3-2.el6.i686
libgcc-4.4.6-3.el6.i386
glibc-2.12-1.47.el6_2.9.i686
libuuid-2.17.2-12.4.el6.i686
libXau-1.0.5-1.el6.i686
Ci sono anche un mucchio di librerie locali per l'applicazione che ho controllato e sono già installati.

Il mio ambiente

CentOS in esecuzione su VirtualBox

uname -a: Linux localhost.localdomain 2.6.32-358.el6.i686 # 1 SMP Gio 21 feb 12:50:49 UTC 2013 i686 i686 i386 GNU / Linux

centos libraries

— Carl
fonte

1

ipotesi selvaggia: stai cercando di eseguire un binario a 32 bit su un sistema operativo a 64 bit senza librerie a 32 bit installate.

— michas,

È un file binario a 32 bit, ma il sistema operativo che ho installato è la versione a 32 bit di CentOS. Almeno questo è ciò che il comando uname-a mi dice di sì?

— Carl

3

@Carl Per curiosità, cosa produce strace ./uclsyn? Questo potrebbe darci un suggerimento su cosa manca prima.

— lgeorget

@lgeorget, restituisce: execve ("./ uclsyn_linux", ["./uclsyn_linux"], [/ * 56 vars * /] <incompiuto ...> +++ ucciso da SIGKILL +++

— Carl

@Carl Ok, quindi non arriva nemmeno al punto in cui tenta di caricare alcune librerie. Non ho mai provato prima a straceun programma non collegato correttamente.

— lgeorget

13

Ho appena avuto il problema con un binario a 32 bit, la soluzione era:

apt-get install gcc-multilib

$ uname -a
Linux bla 2.6.32-028stab094.3 #1 SMP Thu Sep 22 12:47:37 MSD 2011 x86_64 GNU/Linux

— lama12345
fonte

3

come hai scoperto che mancava quella lib?

— yehudahs

1

Questa soluzione ha funzionato per me. +1

— Spazio frattale

@yehudahs Ho eseguito molte applicazioni precompilate a 32 bit su Linux da un po 'di tempo, oltre a Reverse Engineering, quindi ho raccolto alcune esperienze di risoluzione dei problemi. : D

— lama12345,

1

bello, questo ha funzionato anche per me, mentre mi grattavo la testa per quello che stavo facendo di sbagliato

— Marvin Effing,

1

Funziona anche per me: ldd non ha trovato qualcosa mentre questo funziona ^^

— jy95

8

L'errore qui era dovuto al fatto di non avere abbastanza RAM su VirtualMachine. In esecuzione strace ./programnameindicava che il programma era stato ucciso appena avviato, prima di caricare una delle librerie. L'aumento della quantità di RAM disponibile ha garantito il funzionamento del programma.

Risposte utili

Ci sono state alcune risposte utili da altri, vale a dire @slm, che ha fornito utili comandi per verificare l'esistenza di ciascuna delle librerie, e @lgeorget, che ha suggerito di provare il stracecomando.

— Carl
fonte

5

Puoi pubblicare alcune delle librerie a cui si collega (dal sistema originale)? Potrebbe essere necessario installare solo alcune librerie mancanti.

In genere su un sistema CentOS è solo una questione di eseguire un comando yum in questo modo:

yum install <package name>

Puoi lavorare all'indietro dal sistema originale in questo modo:

$ ldd /bin/ls
    linux-vdso.so.1 =>  (0x00007fff519ff000)
    libselinux.so.1 => /lib64/libselinux.so.1 (0x00000034e8e00000)
    librt.so.1 => /lib64/librt.so.1 (0x00000034e8a00000)
    libcap.so.2 => /lib64/libcap.so.2 (0x0000003d6fe00000)
    libacl.so.1 => /lib64/libacl.so.1 (0x00000034fae00000)
    libc.so.6 => /lib64/libc.so.6 (0x00000034e7200000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00000034e7a00000)
    /lib64/ld-linux-x86-64.so.2 (0x00000034e6e00000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00000034e7e00000)
    libattr.so.1 => /lib64/libattr.so.1 (0x00000034f7600000)

In quell'output puoi vedere dove è la mia copia /bin/ls sta raccogliendo le librerie condivise .so per esempio dire, librt.so.1che succede ad essere situato qui: /lib64/librt.so.1.

Sapendo questo, sul sistema originale, è possibile eseguire questo comando per capire quale pacchetto fornisce questa libreria:

$ rpm -qf /lib64/librt.so.1
glibc-2.13-2.x86_64

Quindi viene chiamato il pacchetto glibc-2.13-2.x86_64. Quindi per installarlo dovresti fare questo:

$ sudo yum install glibc-2.13-2.x86_64

— SLM
fonte

Grazie mille per l'aiuto. Sto andando oltre. Ho aggiornato la mia domanda con qualche informazione in più ora, se vuoi aggiornare la tua risposta con la stessa sarebbe molto apprezzato. :)

— Carl

Hai yum install <package>quei pacchetti a cui hai fatto riferimento nella tua domanda?

— slm

Si l'ho fatto. Sono stati installati tutti tranne libuuid.i686 che è ora, ma ho ancora lo stesso problema.

— Carl

2

La risposta è nella tua domanda: provi a eseguire un'applicazione che è stata compilata per GNU / Linux un anno fa e provi a eseguirla con nuove librerie, che potrebbero non essere più compatibili o disponibili.

A questo punto, hai due scelte. Se riesci a ricompilarlo (che dubito, se capisco bene il tuo caso), verrà eseguito perché verrà ricollegato con librerie compatibili. Altrimenti, potresti provare a creare una specie di sandbox, ad esempio una VM in esecuzione con una vecchia versione delle librerie GNU, per eseguire l'applicazione.

— lgeorget
fonte

1

Questo non è corretto Il programma è staticamente collegato, nessuna libreria sul sistema host verrà referenziata. Mentre l'ABI può ancora causare incompatibilità, è improbabile tra i giri minori del kernel Linux (assumendo la stessa architettura).

— ckhan,

1

Non è staticamente collegato, vedere l'output di file. E messaggi come No package xyz foundsuggeriscono che le librerie necessarie non sono più disponibili (almeno, non com'erano, negli stessi pacchetti). Ecco perché suggerisco di ricostruire il programma, se possibile, o di eseguirlo in un sistema in cui era noto che funzionasse, con vecchie librerie.

— lgeorget,

Purtroppo la ricompilazione non è un'opzione qui. L'ho fatto funzionare su un altro sistema proprio come sto provando qui, ma per qualche ragione, questa volta non mi piace.

— Carl,

Questo è sbagliato. La modifica degli indirizzi non ha alcuna importanza. Le funzioni che vengono rimosse o altre interruzioni ABI si verificano in occasione di revisioni importanti della libreria (che sono rare), nel qual caso, si otterrebbe un errore durante il caricamento di libfoo2 se non hai installato libfoo2, indipendentemente dal fatto che tu abbia installato libfoo3.

— psusi

Ok buono a sapersi. Ho pensato che qualsiasi cambiamento in una libreria potrebbe interrompere il collegamento. Attualmente sto eseguendo un gentoo e spesso devo ricompilare le dipendenze inverse quando aggiorno una libreria, quindi non pensavo che il collegamento fosse così resistente alle modifiche della libreria.

— lgeorget,

0

prova readelf -l uclsyn_linux Richiedere l'interprete del programma ti dirà cosa ti manca.

— netawater
fonte

1

Mi sono imbattuto in readelf -l <file>un file con lo stesso lddcomportamento ( not a dynamic executable), ma non vedo nulla che indichi immediatamente una libreria mancante. Vedo Elf file type is EXEC (Executable file), Entry point, Program Headerse Section to Segment mapping. Cosa devo cercare esattamente nell'output?

— StockB,

0

In Arch Linux , se il file è elf a 32 bit, è possibile installare lib32-gcc-libs (dal repository multilib) per risolvere il problema.

— Uno squalo
fonte