Der Versuch, eine kompilierte ausführbare Datei auf dem Zielgerät auszuführen, schlägt fehl mit: Keine solche Datei oder Verzeichnis

Question

Ich bin in der nicht so sonnigen Welt der Cross-Compilation gefangen.

Ich versuche eine einfache Hallo Welt-Anwendung für meine BeagleBone Black (die einen TI Cortex-A8-Prozessor läuft) zu kompilieren.

Zunächst einmal ich kompiliert und lief erfolgreich die Hallo Welt Anwendung auf x86 mit gcc

Dann änderte ich meine Kompilierungseinstellungen auf die folgenden:

arm-linux-gnueabi-gcc -c -O0 -g3 -Wall main.c -o bin/obj/main.o 
arm-linux-gnueabi-gcc bin/obj/main.o -o bin/hello_world 

ich die Datei über SCP auf die übertragene BeagleBone und ausführbar Erlaubnisse chmod +x hello_world

Auf ihr laufen (./hello_world), meine einzige Antwort ist:

-bash: ./hello_world: No such file or directory 

Der Ausgang des file entspricht dem /sbin/init wie ich erwarten würde:

$ file hello_world 
hello_world: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x24b659b7a41fe043a6f4649d4ebfb5e692ebf0c7, not stripped 
$ file /sbin/init 
/sbin/init: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0xd21f6957ec031a27d567b3d5e6aa14b9e0c30c37, stripped 

Das Ergebnis ldd ist:

$ ldd hello_world 
    not a dynamic executable 

ich eine geeignete Plattform und CPU-Typ versucht, das Hinzufügen, meine Wechsel Zusammenstellung zu:

arm-linux-gnueabi-gcc -c -O0 -g3 -Wall -march=armv7-a -mtune=cortex-a8 main.c -o bin/obj/main.o 
arm-linux-gnueabi-gcc bin/obj/main.o -o bin/hello_world 

Das fing anfänglich an, mir einen neuen Fehler zu geben: , aber ich konnte diesen Fehler seitdem nicht mehr zurückbekommen, da er jetzt No such file or directory zurückgibt. Ich vermute, dass dieser Versuch nur eine schlechte Übertragung war oder so.

Answer 1

Da niemand aus den Kommentaren die Antwort geschrieben, ich denke, ich das Vergnügen bekommen;)

No such file or directory herkommt, wenn der Kernel versucht, den dynamischen Linker von der ELF ausführbaren .interp Feld angegeben aufzurufen, aber keine solche Datei vorhanden ist .

Das .interp Feld kann mit dem folgenden Befehl zu finden:

objdump -j .interp -s ./hello_world 

Im Fall dieses Beispiels der .interp Feld /lib/ld-linux.so.3 war ausführbare, aber der Name des dynamischen Linkers auf dem BeagleBone Schwarz ist /lib/ld-linux-armhf.so.3.

Dies passierte, weil das Programm mit einer etwas anderen Toolchain kompiliert wurde als für die Plattform. Es sollte arm-linux-gnueabihf-* anstatt arm-linux-gnueabi-* sein.

Soweit ich weiß, verwendet der Cortex-A8 hardwarebasierte Fließkommaoperationen in ARMv7, aber frühere Versionen des ARM-Befehlssatzes verwendeten softwarebasierte Techniken. Dies ist der Unterschied zwischen armhf und armel. Als Ergebnis werden armel Programme unter armhf ausgeführt (vorausgesetzt, der dynamische Linker ist auf den richtigen Pfad eingestellt!), Aber nicht umgekehrt.

Das einfache Hinzufügen eines symbolischen Links ln -s /lib/ld-linux-armhf.so.3 /lib/ld-linux.so.3 ist genug, um dieses Problem zu beheben, aber die richtige Lösung besteht darin, beim Kompilieren des Programms die richtige Toolchain zu verwenden.

Answer 2

Ich hatte das gleiche Problem. Ich heruntergeladen und installiert gcc-arm-linuc-gnueabihf Paket auf meinem Ubuntu PC aus dem Ubuntu-Repository mit apt-get. Dann habe ich ein helloworld Testprogramm kompiliert und mit sftp auf meinen BeagleBone heruntergeladen.

Der Versuch, das Programm auf BBB gab den Fehler laufen: „Keine solche Datei oder das Verzeichnis“

Mit objdump ich, dass das Feld .interp /lib/ld_linux_armhf.so.3 war in der ELF ausführbare Datei gefunden. Meine BBB hatte dynamische Linker /lib/ld-linux.so.3.

habe ich einen symbolischen Link auf der BBB:

ln -s /lib/ld-linux.so.3 /lib-linux-armhf.so.3 

Nun ist die Quer kompilierte Anwendung arbeitet auf BBB. Die BBB läuft die ursprüngliche Angstrom-Verteilung.

Dies ist nicht die ideale Lösung. Jetzt muss ich entweder die Toolchain in Ubuntu konfigurieren, um der App den korrekten dynamischen Linkernamen hinzuzufügen, oder die BBB aktualisieren, damit in der Toolchain ein dynamischer Linker angegeben wird.

Ich nehme an, die Fehlermeldung ist aufgrund der dynamischen Linker-Datei nicht gefunden, nicht, dass die Anwendung nicht existiert.