Kompilacja krzyżowa GNU ARM (BeagleBoneBlack) z systemu Windows. Runtime Error na * .elf: "Brak takiego pliku lub katalogu"

Question

Jestem na (bardzo) wczesnym etapie opracowywania kontrolera lotu UAV na BeagleBone Black. Powinienem wspomnieć, że jestem całkiem początkującym, jeśli chodzi o systemy BBB, Linux i systemy wbudowane. Moje zainteresowania akademickie dotyczyły teorii sterowania - jest to moja pierwsza próba praktycznej implementacji poza Matlab Simulations. Mój obecny system jest następujący:

Host-> Windows 8.1 x64 z systemem Eclipse Luna (4.4.0)
Target -> BeagleBone Black rev. B Ubuntu 13.10

docelowa Informacje

root@arm:~# uname -a 
Linux arm 3.8.13-bone32 #1 SMP Fri Dec 13 20:05:25 UTC 2013 armv7l armv7l   armv7l GNU/Linux 

docelowej wersji GCC

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) 

Mam zainstalowane Sourcery Codebench Lite toolchain i używam GNU Make file. Skonfigurowałem środowisko Eclipse zgodnie z instrukcją wideo dostarczoną przez Michaela Jantza (link usunięty ze względu na limit - jeśli zainteresowane wyszukiwanie "Cross-Compile i Remote Browsing for BeagleBone" na YouTube) z drobnymi poprawkami, aby uruchomić go na moim system. Poprawki te polegały głównie na usunięciu flag "linkspecs = rdimon.specs" i "-lrdimon", ponieważ podczas kompilacji otrzymywałem "brak takiego pliku lub katalogu". Po usunięciu tych dwóch flag prosty program "Hello ARM World" kompiluje się bez żadnych problemów.

Po przeniesieniu skompilowany plik ELF do mojego BeagleBone, określające uprawnienia i wykonywalne flagi poprzez:

chmod ugo-x Test6.elf 

i uruchomienie go za pomocą:

./Test6.elf 

pojawia się następujący komunikat:

root@arm:/home/ubuntu/RDKTestProgs# ./Test6.elf 
bash: ./Test6.elf: No such file or directory 

Początkowo sądziłem, że niedopasowanie między moim 64-bitowym systemem hosta a 32-bitowym GNU Make nie powinno być problemem, ale aby wyeliminować moje wątpliwości znalazłem 64-bitowy plik GNU Make (link został usunięty z powodu ograniczeń), chociaż nie jestem pewien jego integralności. W każdym przypadku oba pliki GNU Make dają taki sam wynik, gdy próbuje się uruchomić program na BBB.

Po przejrzeniu kilku postów odkryłem narzędzia "readelf", "strace" i "strings", które dały następujące wyniki.

readelf:

root@arm:/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 
root@arm:/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:

root@arm:/home/ubuntu/RDKTestProgs# strace ./Test6 
strace: Can't stat './Test6': No such file or directory 
root@arm:/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 +++ 

Struny:

root@arm:/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! 

Szukałem przez moją BeagelBoneBlack dla 4 dodanych plików bibliotecznych wskazane z funkcją „readelf” i odkryli, że są w rzeczywistości obecni. Problem polega jednak na tym, że niektóre z tych plików znajdują się w katalogu usr/lib/arm-linux-gnueabihf /, podczas gdy inne znajdują się w katalogu/lib/arm-linux-gnueabihf #. Aby to naprawić, utworzyłem dowiązania symboliczne do plików nie znajdujących się w katalogu/usr/lib/arm-linux-gnueabihf /. To nadal nie rozwiązało problemu. Stworzyłem więc dowiązania symboliczne do plików, których nie ma w katalogu/lib/arm-linux-gnueabihf /. Znowu nie ma szczęścia.

Czy istnieje sposób sprawdzenia, który katalog jest używany podczas wykonywania? Czego jeszcze nie ma w pliku Test6.elf? W tej chwili jestem zagubiony. Wszelkie porady i wskazówki będą mile widziane! Twoje zdrowie!

P.S. Udało mi się również sprawdzić GLIBCXX_3.4, GLIBC_2.4 i GCC_3.5, jak pokazano poniżej, ale znowu niektóre z nich odnoszą się do plików w/usr/lib/arm-linux-gnueabihf innych znajdują się w/lib/arm-linux-gnueabihf. Dzięki jeszcze raz!

root@arm:/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 

root@arm:/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 

I wreszcie, oto programowi

//============================================================================ 
// 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; 
} 

Answer 1

Prawo na ARM "Hello World"! Więc działam. Oto moje kroki, mam nadzieję, że są w porządku i nie będą powodować problemów w przyszłości.

1. Od this post próbowałem dowiedzieć się, gdzie spodziewał się znaleźć Test6.elf ładowarka Linux dla dynamicznie połączonych bibliotek. To dało:

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

2. Sprawdziłem /lib folder i na pewno wystarczy plik ld-linux.so.3 brakowało. Zamiast tego znalazłem go w folderze /lib/arm-linux-gnueabihf/

3. Więc stworzyłem dowiązania symbolicznego w katalogu/lib poprzez:

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

i bom! To działa. Co mogę jeszcze znaleźć dziwne jest jednak to, że wciąż powraca ldd ./Test6.elf:

root@arm:/home/ubuntu/RDKTestProgs# ldd ./Test6.elf 
not a dynamic executable 

Czy istnieje dobry powód do tego, czy jest to jakoś normalne? - Nie wydaje mi się to właściwe.

Zauważyłem również, że moje bieżące ustawienia kompilatora (a tym samym toolchain) dla Float ABI są ustawione na miękkie, ale mój BeagleBoneBlack działa arm-linux-gnueabihf - hard float. Czy spowoduje to problemy w przyszłości? Czy powinienem szukać innego zestawu narzędzi?

Pozdrawiam!

Answer 2

Miałem podobną sytuację z biblioteką o nazwie "ibstdC++. So.6". Rozwijam się w Eclipse na Ubuntu 14.04 i wdrażam na beaglebone w Debianie. Nigdy wcześniej nie miałem tego problemu, kiedy korzystałem z Eclipse Ubuntu 12.04 i instalowałem na Amstrong.

Sposób, w jaki udało mi się rozwiązać problem, polegający na przeczytaniu powyższych anwsers i co zrobiłem, ustawił mój krzyżowy kompilator na uzbrojenie-linux-gnueabihf-g ++. Wydaje się, że biblioteka, której mi brakowało, jest zawarta w twardej, pływającej wersji kompilatora, a nie w miękkim zawieszeniu. Zmień ustawienie cross kompilatora w Eclipse i rozwiązaj problem.