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

8

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

Ich versuche eine einfache Hallo-Welt-Anwendung für mein BeagleBone Black (das einen TI Cortex-A8-Prozessor ausführt) zu kompilieren.

Zuerst habe ich die Hallo-Welt-Anwendung auf x86 mit gcc

kompiliert und erfolgreich ausgeführt

Dann habe ich meine Kompilierungseinstellungen wie folgt geändert:

%Vor%

Ich habe die Datei per SCP in den BeagleBone übertragen und ausführbare Berechtigungen mit chmod +x hello_world

gesetzt

Beim Ausführen ( ./hello_world ) ist meine einzige Antwort:

%Vor%

Die Ausgabe von file stimmt mit der von /sbin/init überein, wie ich es erwarten würde:

%Vor%

Das Ergebnis von ldd ist:

%Vor%

Ich habe versucht, eine geeignete Plattform und einen geeigneten CPU-Typ hinzuzufügen und ändere meine Zusammenstellung in:

%Vor%

Das fing an, mir einen neuen Fehler zu geben: Text file busy , aber ich konnte diesen Fehler nicht mehr zurückbekommen, da er nun No such file or directory zurückgibt. Ich vermute, dass ein bestimmter Versuch nur eine schlechte Übertragung oder etwas war.

    
CJxD 10.08.2015, 21:01
quelle

2 Antworten

12

Da niemand aus den Kommentaren die Antwort gepostet hat, schätze ich das Vergnügen;)

No such file or directory kommt von, wenn der Kernel versucht, den dynamischen Linker aufzurufen, der im Feld .interp der ELF-Programmdatei angegeben ist, aber keine solche Datei existiert.

Das Feld .interp kann mit dem folgenden Befehl gefunden werden:

%Vor%

In diesem Beispiel war das .interp -Feld der ausführbaren Datei /lib/ld-linux.so.3 , aber der Name des dynamischen Linkers auf dem BeagleBone Black 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 auf armhf ausgeführt (vorausgesetzt, der dynamische Linker ist auf den richtigen Pfad gesetzt!), Aber nicht umgekehrt.

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

    
CJxD 11.08.2015, 16:18
quelle
2

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

Der Versuch, das Programm auf BBB auszuführen, gab den Fehler: "Keine solche Datei oder Verzeichnis"

Mit objdump habe ich festgestellt, dass das Feld .interp in der ausführbaren ELF-Datei /lib/ld_linux_armhf.so.3 ist. Meine BBB hatte den dynamischen Linker /lib/ld-linux.so.3 .

Ich habe einen symbolischen Link auf der BBB erstellt:

%Vor%

Jetzt funktioniert die Cross-kompilierte Anwendung 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.

    
Phil Matthews 01.12.2016 03:13
quelle