Ausführen einer Binärdatei: Datei nicht gefunden

9

Ich weiß, dass es ähnliche Fragen gibt, aber ich habe weder eine Lösung noch genau diesen Fall gefunden. Die Binärdatei wurde unter Arch Linux mit GCC 4.7 erstellt. Das Paket funktioniert gut auf dem Build-System. Die folgenden Befehle wurden ausgeführt am:

Linux vbox-ubuntu 3.2.0-29-generic # 46-Ubuntu SMP Fr 27. Juli 17:03:23 UTC 2012 x86_64 x86_64 x86_64 GNU / Linux

Die betreffende Datei befindet sich hier . Es ist ein Linux 64-Bit zu Windows 64-Bit Cross-Compiler. Wenn Sie die Verknüpfung aufheben, erhalten Sie ~/ein einziges ~/mingw64Verzeichnis, das alles Notwendige enthält.

Wenn ich versuche zu laufen, ~/mingw64/x86_64-w64-mingw32/bin/asbekomme ich Folgendes:

bash: /home/ruben/mingw64/x86_64-w64-mingw32/bin/as: No such file or directory

Laufen file ~/mingw64/x86_64-w64-mingw32/bin/asgibt mir:

/home/ruben/mingw64/x86_64-w64-mingw32/bin/as: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x0b8e50955e7919b76967bac042f49c5876804248, not stripped

Laufen ldd ~/mingw64/x86_64-w64-mingw32/bin/asgibt mir:

    linux-vdso.so.1 =>  (0x00007fff3e367000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f2ceae7e000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2ceaac1000)
    /lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f2ceb0a8000)

Ich bin wirklich ratlos. Jede Hilfe wird sehr geschätzt.

EDIT : Einige weitere Details: Das Build-System ist Arch Linux (derzeit glibc 2.16). Die Ausgabe von ls -list:

-rwxr-xr-x 2 ruben users 1506464 11 aug 23:49 /home/ruben/mingw64/bin/x86_64-w64-mingw32-as

Die Ausgabe von objdump -pist:

Version References:
  required from libz.so.1:
    0x0827e5c0 0x00 05 ZLIB_1.2.0
  required from libc.so.6:
    0x0d696917 0x00 06 GLIBC_2.7
    0x06969194 0x00 04 GLIBC_2.14
    0x0d696913 0x00 03 GLIBC_2.3
    0x09691a75 0x00 02 GLIBC_2.2.5

Die Ausgabe von ldd -vunter Ubuntu 12.04 ist:

    linux-vdso.so.1 =>  (0x00007fff225ff000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fd525c71000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd5258b4000)
/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007fd525e9b000)

Version information:
/home/ruben/mingw64/x86_64-w64-mingw32/bin/as:
    libz.so.1 (ZLIB_1.2.0) => /lib/x86_64-linux-gnu/libz.so.1
    libc.so.6 (GLIBC_2.7) => /lib/x86_64-linux-gnu/libc.so.6
    libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6
    libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6
    libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
/lib/x86_64-linux-gnu/libz.so.1:
    libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6
    libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6
    libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
/lib/x86_64-linux-gnu/libc.so.6:
    ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2
    ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2

Die getesteten anderen Betriebssysteme sind Fedora 17 (glibc 2.15) und Ubuntu 12.04 (eglibc 2.15). Sowohl die zlib- als auch die glibc-Versionsanforderungen werden erfüllt.

ubuntu files compiling binary patchelf rubenvb
quelle
Ist es nur ein Tippfehler oder versuchen Sie tatsächlich, '~ / mingw64 / x86_64-w64-mingw32 / as' auszuführen? ... es fehlt der Ordner 'bin'.
verdreifacht
@tripledes Typ und korrigiert.
Rubenvb
seltsam, habe gerade versucht herunterzuladen, entpacke unter meinem ~ und ich bekomme das erwartete Ergebnis. Könnten Sie ein ls -l ~ / mingw64 / x86_64-w64-mingw32 / bin / as angeben?
verdreifacht
1
Könnte es sich um eine Nichtübereinstimmung der libc-Version handeln? Versuchen Sie, "objdump -p <path / to / as>" auszuführen, und überprüfen Sie den Abschnitt "Versionsreferenzen". Es könnte so aussehen, als ob es von GLIBC_2.14 abhängt, was als ziemlich neu angesehen werden könnte. Was ist Ihre Systemversion? "readelf -a <path / to / as> | less" und grep für GLIBC, Sie werden sehen, dass memcpy ab 2.14 verwendet wird. Ich weiß nicht, warum die Version zwischen verschiedenen Bibliotheksaufrufen so stark variieren würde.
Svenx

Antworten:

8

Wenn ich ldd -v asauf meinem System laufe , bekomme ich:

./as: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by ./as)
        linux-vdso.so.1 =>  (0x00007fff89ab1000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f1e4c81f000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1e4c498000)
        /lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f1e4ca6d000)

Es sieht also so aus, als würden diese Binärdateien nach einem GLIBC_2.14Symbol suchen , das Ihnen vermutlich auf Ihrem System fehlt. Wie svenx hervorhob, sieht es so aus, als würde nach dem memcpy@@GLIBC_2.14Symbol gesucht . Weitere Informationen darüber, warum memcpyeine neue Version erhalten wurde, finden Sie in diesem Fehlerbericht .

Die Installation einer neuen Version von glibcauf Ihrem Zielsystem sollte das Problem beheben. Wenn Sie versuchen möchten, die Binärdatei neu zu erstellen, damit sie weiterhin mit der alten Version von funktioniert glibc, können Sie Tricks wie den hier aufgeführten ausprobieren . Sie könnten vielleicht auch mit einer Unterlegscheibe auskommen, die nur die spezifische Version des memcpySymbols enthält, die Sie benötigen, aber das wird ein bisschen hackig.

Nachdem Sie Ihr Update gelesen haben : Sie haben Recht, das war nicht Ihr Problem. Aber ich glaube, ich habe es gefunden: Ihre Binärdatei fordert den Interpreter an /lib/ld-linux-x86-64.so.2, der auf Ubuntu 12.04-Systemen nicht vorhanden ist:

$ readelf -a ./as | grep interpreter
      [Requesting program interpreter: /lib/ld-linux-x86-64.so.2]

Obwohl ich wusste, dass ich lddes /lib64stattdessen finden muss, weiß der Kernel das wohl nicht, wenn er versucht, die Binärdatei auszuführen, und kann den angeforderten Interpreter der Datei nicht finden. Sie können versuchen, es einfach manuell durch den Interpreter zu führen:

$ pwd
/home/jim/mingw64/x86_64-w64-mingw32/bin
$ ./as --version
-bash: ./as: No such file or directory
$ /lib64/ld-linux-x86-64.so.2 ./as --version
GNU assembler (rubenvb-4.7.1-1-release) 2.23.51.20120808
Copyright 2012 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `x86_64-w64-mingw32'.

Ich bin nicht zu 100% sicher, dass dies korrekt funktioniert. Auf meinem System führt die Ausführung auf gccdiese Weise zu einem Segmentierungsfehler. Aber das ist zumindest ein anderes Problem.

Jim Paris
quelle
1
Das wäre schön gewesen, wenn dies der Fall wäre. Siehe Update:(
Rubenvb
Ich habe meine Antwort aktualisiert.
Jim Paris
Wow OK. Diese Art von saugt. Ich kann mir keinen vernünftigen Weg vorstellen, um dieses Problem zu umgehen (und weiter auf Arch aufzubauen). Hast du irgendwelche genialen Ideen?
Rubenvb
1
Nicht wirklich. Arch ist einfach nur dumm - der Dateisystem-Heirarchy-Standard sagt eindeutig, dass Bibliotheken /lib64auf amd64 sein sollten, und anscheinend patcht Arch manuell ihre gcc-Quellen, um dies zu ändern, wodurch die Inkompatibilität mit jeder anderen Linux-Distribution da draußen garantiert wird. In den Kommentaren dieses Fehlerberichts finden Sie die bizarren Gründe. Für mich wäre dies ein klares Warnsignal, um sich von Arch Linux fernzuhalten.
Jim Paris
1
Sie können den Interpreter-Speicherort jedoch mit patchelf ändern . In diesem Beitrag finden Sie eine andere Person, die auf dieses Problem stößt und behauptet, dass dies patchelffür sie funktioniert hat.
Jim Paris
0

Ihr Problem ist eine Variante der Meldung "Nicht gefunden", wenn eine 32-Bit-Binärdatei auf einem 64-Bit-System ausgeführt wird : Sie haben eine ausführbare Datei, die einen dynamischen Loader erwähnt, der nicht vorhanden ist.

In Ihrem Fall befindet sich der dynamische Lader /lib/ld-linux-x86-64.so.2an einem anderen Ort /lib64/ld-linux-x86-64.so.2. Der einfachste Weg, um Ihre Programme zum Laufen zu bringen, besteht darin, eine symbolische Verknüpfung zu erstellen:

ln -s ../lib64/ld-linux-x86-64.so.2 /lib/
Gilles 'SO - hör auf böse zu sein'
quelle
Nun, da dies ein Paket ist, das für die Neuverteilung gedacht ist, liegt ein solcher Symlink nicht wirklich in meiner Kontrolle. Ich dachte, Linux-Binärdateien wären portabler ... rate mal nicht.
Rubenvb