ldd sagt mir, dass meine App "keine dynamische ausführbare Datei" ist

17

Ich habe eine 32-Bit-Anwendung (Uclsyn), die ich von einem Astronomieprofessor erhalten habe. Ich habe es vor einem Jahr geschafft, es auf CentOS zum Laufen zu bringen, aber jetzt, wenn ich eine neue CentOS-VM einrichte, läuft es nicht und ich kann nicht herausfinden, warum. Es kommt immer wieder mit "Killed".

Dies ist der Austausch in der Befehlszeile:

$ ./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

Auf dem Computer, auf dem ausgeführt wird, gibt "ldd ./uclsyn_linux" eine ganze Liste von Abhängigkeiten zurück. Ich habe die Pakete gefunden, die diese gemeinsam genutzten Bibliotheken enthalten, und alle scheinen installiert zu sein.

Pakete erforderlich

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
Es gibt auch einen Haufen lokaler Bibliotheken für die Anwendung, die ich überprüft habe und die bereits installiert sind.

Meine Umgebung

CentOS läuft unter VirtualBox

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

centos libraries

— Carl
quelle

1

Vermutung: Sie versuchen, eine 32-Bit-Binärdatei auf einem 64-Bit-Betriebssystem ohne installierte 32-Bit-Bibliotheken auszuführen.

— Michas

Es ist eine 32-Bit-Binärdatei, aber das von mir installierte Betriebssystem ist die 32-Bit-Version von CentOS. Zumindest sagt mir das uname-a-Kommando ja?

— Carl

3

@Carl Aus Neugier, was macht die strace ./uclsynAusgabe? Das kann uns einen Hinweis darauf geben, was zuerst fehlt.

— Dienstag,

@lgeorget, Es wird zurückgegeben: execve ("./uclsyn_linux", ["./uclsyn_linux"], [/ * 56 vars * /] <unvollendet ...> +++ von SIGKILL getötet +++

— Carl

@Carl Ok, es geht also nicht einmal bis zu dem Punkt, an dem versucht wird, einige Bibliotheken zu laden. Ich habe noch nie versucht, straceein Programm nicht richtig verknüpft.

— Lgeorget

13

Ich hatte gerade das Problem mit einer 32-Bit-Binärdatei. Die Lösung war:

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
quelle

3

Wie haben Sie festgestellt, dass diese Bibliothek fehlt?

— Yehudahs

1

Diese Lösung hat bei mir funktioniert. +1

— FractalSpace

@yehudahs Ich habe eine ganze Weile lang viele vorkompilierte 32-Bit-Anwendungen unter Linux ausgeführt und sie auch rückgängig gemacht, sodass ich einige Erfahrungen bei der Fehlersuche gesammelt habe. : D

— lama12345

1

Schön, das funktionierte für mich und ich kratzte mir am Kopf, was ich falsch gemacht habe

— Marvin Effing

1

Funktioniert auch für mich: ldd hat nichts gefunden, während dies funktioniert ^^

— jy95

8

Der Fehler war darauf zurückzuführen, dass nicht genügend RAM auf der VirtualMachine vorhanden war. Wird ausgeführt strace ./programnamebedeutet, dass das Programm gerade beendet wurde, als es gestartet wurde, bevor eine der Bibliotheken geladen wurde. Durch Erhöhen des verfügbaren Arbeitsspeichers konnte sichergestellt werden, dass das Programm funktioniert.

Nützliche Antworten

Es gab einige nützliche Antworten von anderen, nämlich von @slm, der nützliche Befehle zur Überprüfung der Existenz der einzelnen Bibliotheken zur Verfügung stellte, und von @lgeorget, der den Versuch des straceBefehls vorschlug .

— Carl
quelle

5

Können Sie einige der Bibliotheken veröffentlichen, auf die der Link verweist (vom ursprünglichen System)? Möglicherweise müssen Sie nur einige fehlende Bibliotheken installieren.

In der Regel muss auf einem CentOS-System nur ein yum-Befehl wie folgt ausgeführt werden:

yum install <package name>

Sie können vom ursprünglichen System aus wie folgt rückwärts arbeiten:

$ 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 diesem Ausgang können Sie sehen , wo meine Kopie /bin/lswird die gemeinsamen .so Bibliotheken für beispielsweise, Aufnehmen librt.so.1, die hier angesiedelt werden , geschieht: /lib64/librt.so.1.

Wenn Sie dies wissen, können Sie auf dem ursprünglichen System diesen Befehl ausführen, um herauszufinden, welches Paket diese Bibliothek enthält:

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

Also heißt das Paket glibc-2.13-2.x86_64. Um es zu installieren, machen Sie folgendes:

$ sudo yum install glibc-2.13-2.x86_64

— slm
quelle

Vielen Dank für die Hilfe. Ich komme weiter. Habe meine Frage jetzt mit einigen weiteren Informationen aktualisiert. Wenn Sie Ihre Antwort mit denselben Informationen aktualisieren möchten, wäre dies sehr dankbar. :)

— Carl

Haben Sie yum install <package>die Pakete, auf die Sie in Ihrer Frage verwiesen haben?

— slm

Ja, habe ich. Sie wurden alle installiert, bis auf libuuid.i686, das ist jetzt, aber ich habe immer noch das gleiche Problem.

— Carl

2

Die Antwort liegt in Ihrer Frage: Sie versuchen, eine Anwendung auszuführen, die vor einem Jahr für GNU / Linux kompiliert wurde, und Sie versuchen, sie mit neuen Bibliotheken auszuführen, die möglicherweise nicht kompatibel oder nicht mehr verfügbar sind.

Zu diesem Zeitpunkt haben Sie zwei Möglichkeiten. Wenn Sie es erneut kompilieren können (was ich bezweifle, wenn ich Ihren Fall gut verstehe), wird es ausgeführt, da es mit kompatiblen Bibliotheken neu verknüpft wird. Andernfalls könnten Sie versuchen, eine Art Sandbox zu erstellen, z. B. eine VM, die mit einer alten Version der GNU-Bibliotheken ausgeführt wird, um die Anwendung auszuführen.

— lgeorget
quelle

1

Das ist nicht richtig. Das Programm ist statisch verknüpft, es werden keine Bibliotheken auf dem Host-System referenziert. Während die ABI immer noch zu Inkompatibilität führen kann, ist es unwahrscheinlich, dass zwischen kleineren Revisionen des Linux-Kernels (unter der Annahme der gleichen Architektur) eine Inkompatibilität auftritt.

— ckhan

1

Es ist nicht statisch verknüpft, siehe die Ausgabe von file. Und Meldungen wie No package xyz founddeuten darauf hin, dass die benötigten Bibliotheken nicht mehr verfügbar sind (zumindest nicht so, wie sie waren, in denselben Paketen). Aus diesem Grund empfehle ich, das Programm neu zu erstellen, falls dies möglich ist, oder es in einem System mit alten Bibliotheken auszuführen, von dem bekannt war, dass es funktioniert.

— Lgeorget

Ein erneutes Kompilieren ist hier leider nicht möglich. Ich habe es auf einem anderen System laufen lassen, genauso wie ich es hier versuche, aber aus irgendeinem Grund gefällt es mir diesmal nicht.

— Carl

Das ist falsch. Das Ändern von Adressen spielt überhaupt keine Rolle. Funktionen, die entfernt werden, oder andere ABI-Unterbrechungen treten bei Hauptversionen der Bibliothek auf (was selten vorkommt). In diesem Fall wird beim Laden von libfoo2 ein Fehler angezeigt, wenn libfoo2 nicht installiert ist, unabhängig davon, ob libfoo3 installiert ist oder nicht.

— Psusi

Ok, gut zu wissen. Ich dachte, dass jede Änderung in einer Bibliothek die Verknüpfung unterbrechen könnte. Ich verwende derzeit ein Gentoo und muss die umgekehrten Abhängigkeiten oft neu kompilieren, wenn ich eine Bibliothek aktualisiere. Daher war das Verknüpfen für mich nicht so widerstandsfähig gegen Bibliotheksänderungen.

— Lgeorget

0

versuchen , readelf -l uclsyn_linux Programm - Interpreter anfordern wird Ihnen sagen , was Sie fehlt.

— netawater
quelle

1

Ich bin auf readelf -l <file>eine Datei mit dem gleichen lddVerhalten gestoßen ( not a dynamic executable), sehe aber nichts, was auf eine fehlende Bibliothek hinweist. Ich sehe Elf file type is EXEC (Executable file), Entry point, Program Headersund Section to Segment mapping. Worauf sollte ich bei der Ausgabe genau achten?

— StockB

0

Wenn die Datei in Arch Linux 32-Bit-Elf ist, können Sie lib32-gcc-libs (aus dem Multilib-Repository) installieren , um das Problem zu beheben.

— Ein Hai
quelle