2014-07-03 11 views
6

Ich bin in der (sehr) frühen Phase der Entwicklung eines UAV Flugcontrollers auf einem BeagleBone Black. Ich sollte erwähnen, dass ich ziemlich Anfänger bin, wenn es um die BBB, Linux und eingebettete Systeme geht. Mein akademischer Fokus lag auf der Steuerungstheorie - dies ist mein erster Versuch einer praktischen Implementierung außerhalb von Matlab Simulations. Mein aktuelles System ist wie folgt:Kreuzkompilierter GNU ARM (BeagleBoneBlack) von Windows. Laufzeitfehler bei * .elf: "Keine solche Datei oder Verzeichnis"

Host-> Windows 8.1 x64 mit Eclipse Luna (4.4.0)
Ziel -> BeagleBone Black rev. B Ubuntu 13.10

Ziel Info

[email protected]:~# uname -a 
Linux arm 3.8.13-bone32 #1 SMP Fri Dec 13 20:05:25 UTC 2013 armv7l armv7l   armv7l GNU/Linux 

Ziel gcc Version

Using built-in specs. 
COLLECT_GCC=gcc 
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.8/lto-wrapper 
Target: arm-linux-gnueabihf 
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.8.1-10ubuntu9' --with-bugurl=file:///usr/shar 
e/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 
--enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --w 
ith-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enabl 
e-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libitm --disable-libquadmath --ena 
ble-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr 
/lib/jvm/java-1.5.0-gcj-4.8-armhf/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-armhf -- 
with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-armhf --with-arch-directory=arm --with-ecj-jar=/usr/share/ja 
va/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --enable-multilib --disable-sjlj-exceptions --with-arch=armv7- 
a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --disable-werror --enable-checking=release --build=arm-lin 
ux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf 
Thread model: posix 
gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu9) 

ich die Sourcery Codebench Lite Werkzeugkette installiert haben und die GNU Make file verwende. Ich habe die Eclipse-Umgebung gemäß dem Lehrvideo von Michael Jantz eingerichtet (Link entfernt wegen Limit - wenn interessiert "Cross-Compile und Remote Browsing für BeagleBone" auf YouTube) mit ein paar kleinen Verbesserungen, um es auf meinem laufen zu lassen System. Diese Verbesserungen bestanden hauptsächlich darin, die Verknüpfungsflags "--specs = rdimon.specs" und "-lrdimon" zu entfernen, da ich beim Kompilieren immer eine "keine solche Datei oder ein solches Verzeichnis" erhielt. Mit diesen beiden Flags wird das einfache Programm "Hello ARM World" ohne Probleme kompiliert.

Nachdem die kompilierte ELF-Datei auf meinem BeagleBone übertragen, das Festlegen von Berechtigungen und die ausführbaren Flags über:

chmod ugo-x Test6.elf 

und es läuft über:

./Test6.elf 

bekomme ich folgende Meldung:

[email protected]:/home/ubuntu/RDKTestProgs# ./Test6.elf 
bash: ./Test6.elf: No such file or directory 

Ich dachte zunächst die Diskrepanz zwischen meinem 64-Bit-Host-System und dem 32-Bit GNU Make sollte kein Problem sein, aber um meine Zweifel zu beseitigen, habe ich eine 64-Bit-GNU-Make-Datei gefunden (Link wegen Limit entfernt), obwohl ich mir seiner Integrität nicht sicher bin. In jedem Fall ergeben beide GNU-Make-Dateien das gleiche Ergebnis, wenn sie versuchen, das Programm auf der BBB auszuführen.

Nachdem ich mehrere Beiträge durchgesehen habe, habe ich die Tools "readelf", "strace" und "strings" entdeckt, die zu folgenden Ausgaben geführt haben.

readelf:

[email protected]:/home/ubuntu/RDKTestProgs# readelf -d Test6.elf 
Dynamic section at offset 0x858 contains 27 entries: 
Tag  Type       Name/Value 
0x00000001 (NEEDED)      Shared library: [libc.so.6] 
0x00000001 (NEEDED)      Shared library: [libstdc++.so.6] 
0x00000001 (NEEDED)      Shared library: [libm.so.6] 
0x00000001 (NEEDED)      Shared library: [libgcc_s.so.1] 
0x0000000c (INIT)      0x8550 
0x0000000d (FINI)      0x87a0 
0x00000019 (INIT_ARRAY)     0x10848 
0x0000001b (INIT_ARRAYSZ)    8 (bytes) 
0x0000001a (FINI_ARRAY)     0x10850 
0x0000001c (FINI_ARRAYSZ)    4 (bytes) 
0x00000004 (HASH)      0x8168 
0x00000005 (STRTAB)      0x82bc 
0x00000006 (SYMTAB)      0x81bc 
0x0000000a (STRSZ)      444 (bytes) 
0x0000000b (SYMENT)      16 (bytes) 
0x00000015 (DEBUG)      0x0 
0x00000003 (PLTGOT)      0x10958 
0x00000002 (PLTRELSZ)     72 (bytes) 
0x00000014 (PLTREL)      REL 
0x00000017 (JMPREL)      0x8508 
0x00000011 (REL)      0x84f8 
0x00000012 (RELSZ)      16 (bytes) 
0x00000013 (RELENT)      8 (bytes) 
0x6ffffffe (VERNEED)     0x8498 
0x6fffffff (VERNEEDNUM)     3 
0x6ffffff0 (VERSYM)      0x8478 
0x00000000 (NULL)      0x0 
[email protected]:/home/ubuntu/RDKTestProgs# strings Test6.elf 
/lib/ld-linux.so.3 
libc.so.6 
abort 
__libc_start_main 
__aeabi_atexit 
libstdc++.so.6 
__gmon_start__ 
_Jv_RegisterClasses 
_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc 
_ITM_deregisterTMCloneTable 
_ITM_registerTMCloneTable 
_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_ 
_ZNSt8ios_base4InitD1Ev 
_ZNSolsEPFRSoS_E 
_ZNSt8ios_base4InitC1Ev 
_ZSt4cout 
libm.so.6 
libgcc_s.so.1 
__aeabi_unwind_cpp_pr0 
__aeabi_unwind_cpp_pr1 
GLIBCXX_3.4 
GCC_3.5 
GLIBC_2.4 
?8FAFJF 
x`9`{h 
Hello ARM World! 

Strace:

[email protected]:/home/ubuntu/RDKTestProgs# strace ./Test6 
strace: Can't stat './Test6': No such file or directory 
[email protected]:/home/ubuntu/RDKTestProgs# strace ./Test6.elf 
execve("./Test6.elf", ["./Test6.elf"], [/* 22 vars */]) = -1 ENOENT (No such file or directory) 
write(2, "strace: exec: No such file or di"..., 40strace: exec: No such file or directory 
) = 40 
exit_group(1)       = ? 
+++ exited with 1 +++ 

Saiten:

[email protected]:/home/ubuntu/RDKTestProgs# strings Test6.elf 
/lib/ld-linux.so.3 
libc.so.6 
abort 
__libc_start_main 
__aeabi_atexit 
libstdc++.so.6 
__gmon_start__ 
_Jv_RegisterClasses 
_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc 
_ITM_deregisterTMCloneTable 
_ITM_registerTMCloneTable 
_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_ 
_ZNSt8ios_base4InitD1Ev 
_ZNSolsEPFRSoS_E 
_ZNSt8ios_base4InitC1Ev 
_ZSt4cout 
libm.so.6 
libgcc_s.so.1 
__aeabi_unwind_cpp_pr0 
__aeabi_unwind_cpp_pr1 
GLIBCXX_3.4 
GCC_3.5 
GLIBC_2.4 
?8FAFJF 
x`9`{h 
Hello ARM World! 

ich durch meinen BeagelBoneBlack nach den 4-Bibliotheksdateien aus dem „readelf“ -Funktion angezeigt geteilt und festgestellt, dass sie tatsächlich anwesend sind. Das Problem ist jedoch, dass sich einige dieser Dateien im Verzeichnis usr/lib/arm-linux-gnueabihf/befinden, während sich andere im Verzeichnis/lib/arm-linux-gnueabihf # befinden. Um das zu beheben, habe ich symbolische Links zu den Dateien erstellt, die nicht im Verzeichnis/usr/lib/arm-linux-gnueabihf/gefunden wurden. Dies hat das Problem immer noch nicht gelöst. Also habe ich symbolische Links zu Dateien erstellt, die nicht im Verzeichnis/lib/arm-linux-gnueabihf/gefunden wurden. Wieder kein Glück.

Gibt es eine Möglichkeit zu überprüfen, welches Verzeichnis bei der Ausführung verwendet wird? Was könnte sonst noch in der Datei Test6.elf fehlen? Ich bin im Moment ratlos. Jeder Rat oder jede Anleitung würde sehr geschätzt werden! Prost!

P.S. Ich habe es auch geschafft, nach GLIBCXX_3.4, GLIBC_2.4 und GCC_3.5 zu suchen, wie unten gezeigt, aber wiederum beziehen sich einige davon auf Dateien in/usr/lib/arm-linux-gnueabihf, andere sind in/lib/zu finden. Arm-Linux-Gnuabihf. Danke noch einmal!

[email protected]:/lib/arm-linux-gnueabihf# strings libgcc_s.so.1 | grep GCC 
GCC_3.0 
GCC_3.3 
GCC_3.3.1 
GCC_3.3.4 
GCC_3.4 
GCC_3.4.2 
GCC_4.0.0 
GCC_4.2.0 
GCC_4.3.0 
GCC_4.7.0 
GCC_3.5 

[email protected]:/usr/lib/arm-linux-gnueabihf# strings libstdc++.so.6.0.18 | grep GLIBC 
GLIBCXX_3.4 
GLIBCXX_3.4.1 
GLIBCXX_3.4.2 
GLIBCXX_3.4.3 
GLIBCXX_3.4.4 
GLIBCXX_3.4.5 
GLIBCXX_3.4.6 
GLIBCXX_3.4.7 
GLIBCXX_3.4.8 
GLIBCXX_3.4.9 
GLIBCXX_3.4.10 
GLIBCXX_3.4.11 
GLIBCXX_3.4.12 
GLIBCXX_3.4.13 
GLIBCXX_3.4.14 
GLIBCXX_3.4.15 
GLIBCXX_3.4.16 
GLIBCXX_3.4.17 
GLIBCXX_3.4.18 
GLIBCXX_3.4.19 
GLIBC_2.4 
GLIBC_2.17 
GLIBCXX_DEBUG_MESSAGE_LENGTH 

Und schließlich ist hier das "Hallo ARM World" Programm

//============================================================================ 
// Name  : main.cpp 
// Author  : RDK 
// Version  : 
// Copyright : Your copyright notice 
// Description : Hello World in C++ 
//============================================================================ 

#include <iostream> 
using namespace std; 

// 
// Print a greeting message on standard output and exit. 
// 
// On embedded platforms this might require semi-hosting or similar. 
// 
// For example, for toolchains derived from GNU Tools for Embedded, 
// to enable semi-hosting, the following was added to the linker: 
// 
// --specs=rdimon.specs -Wl,--start-group -lgcc -lc -lc -lm -lrdimon -Wl,--end-group 
// 
// Adjust it for other toolchains. 
// 

int 
main() 
{ 
    cout << "Hello ARM World!" << endl; 
    return 0; 
} 
+0

+1 Sehr lokalisierte, aber spezifische und explizite Frage. –

+0

Ich vermute, dass Sie einige der dynamisch verknüpften Bibliotheken für Ihre Binärdatei vermissen. Versuchen Sie 'ldd./Test6.elf' zu verwenden und sehen Sie, ob eine der aufgelisteten Bibliotheken als nicht vorhanden angezeigt wird. – msandiford

+0

Danke @msandiford. Ja, das hatte ich auch versucht. Ich bin mir nicht sicher, ob dieses Ergebnis sinnvoll ist: 'ubuntu @ arm: ~/RDKTestProgs $ ldd ./Test6.elf nicht eine dynamische ausführbare Datei – RDK

Antwort

3

auf der rechten! Also ich habe es funktioniert. Hier sind meine Schritte, hoffentlich sind sie gesund und werden mir in Zukunft keine Probleme bereiten.

  1. Von this post, habe ich versucht, um herauszufinden, wo die Test6.elf die Linux-Loader für dynamisch verknüpfte Bibliotheken finden erwartet. Dies ergab:

    [email protected]:/home/ubuntu/RDKTestProgs# readelf -l ./Test6.elf | grep ld-linux [Requesting program interpreter: /lib/ld-linux.so.3]

  2. Ich habe meine /lib Ordner und sicher genug, die ld-linux.so.3 Datei fehlte. Stattdessen fand ich es im /lib/arm-linux-gnueabihf/ Ordner

  3. Also habe ich einen symbolischen Link in/lib Ordner über:

    ln -s /lib/arm-linux-gnueabihf/ld-linux.so.3 /lib/ld-linux.so.3

Und boom! Es klappt. aber was ich noch seltsam finde ist, dass die ldd ./Test6.elf noch zurückgibt:

[email protected]:/home/ubuntu/RDKTestProgs# ldd ./Test6.elf 
not a dynamic executable 

Gibt es einen guten Grund dafür, oder ist das irgendwie normal? - Es scheint mir nicht richtig zu sein.

Ich bemerkte auch, dass meine aktuellen Compiler-Einstellungen (und damit Toolchain) für Float ABI auf weich eingestellt sind, aber mein BeagleBoneBlack läuft arm-linux-gnueabihf - hard float. Wird mir das in der Zukunft Probleme bereiten? Sollte ich nach einer anderen Toolchain suchen?

Prost!

0

Ich hatte eine ähnliche Situation mit einer Bibliothek namens 'ibstdC++. So.6'. Ich entwickle in Eclipse unter Ubuntu 14.04 und deploye auf Beaglebone mit Debian. Ich hatte dieses Problem nie zuvor, als ich auf Eclipse Ubuntu 12.04 entwickelt und auf Amstrong deployen.

Die Art und Weise, wie ich das Problem löste, war das Lesen der Anwser oben und was ich getan habe, setzte ich meinen Cross-Compiler auf arm-linux-gnueabihf-g ++. Scheint, dass die Bibliothek, die mir fehlte, nur in der Hard-Floating-Version des Compilers enthalten ist und nicht im Soft-Floating. Ändern Sie die Cross-Compiler-Einstellung in Eclipse und löste das Problem.

+0

Hey @ Pablo, ja ich habe das auch bemerkt. Ich verwendete die Sourcery CodeBench Toolchain, die Soft-Float verwendet. Ich, der Linaro GCC auf meinem BeagleboneBlack, benutze den Hard-Float, also bin ich gerade auf die Linaro Toolchain umgestiegen und hoffentlich wird das zukünftige Fehler auf der ganzen Linie verhindern. Prost! – RDK