GNU ARM cross-Compilato (BeagleBoneBlack) da Windows. Errore di runtime su * .elf: "Nessun file o directory"

Question

Sono nelle (molto) prime fasi di sviluppo di un controller di volo UAV su un BeagleBone Black. Devo dire che sono abbastanza inesperto quando si parla di BBB, Linux e sistemi embedded. Il mio focus accademico è stato sulla teoria del controllo: questo è il mio primo tentativo di implementazione pratica al di fuori di Matlab Simulations. Il mio sistema attuale è la seguente:

Host-> di Windows 8.1 x64 in esecuzione Eclipse Luna (4.4.0)
Target -> BeagleBone Nero rev. B con Ubuntu 13.10

Info destinazione

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 

target versione di 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) 

Ho installato il Sourcery Codebench Lite toolchain e sto usando il GNU Make file. Ho impostato l'ambiente Eclipse secondo il video didattico fornito da Michael Jantz (link rimosso a causa del limite - se la ricerca interessata "Cross-Compile e Remote Browsing per BeagleBone" su YouTube) con alcune piccole modifiche per farlo funzionare sul mio sistema. Queste modifiche consistevano principalmente nel rimuovere i flag "--specs = rdimon.specs" e "-lrdimon" mentre continuavo a ricevere "nessun file o directory" durante la compilazione. Con questi due flag rimosso il semplice programma "Hello ARM World" viene compilato senza problemi.

Dopo il trasferimento del file ELF compilato al mio BeagleBone, i permessi e le bandiere eseguibili tramite:

chmod ugo-x Test6.elf 

e funzionante tramite:

./Test6.elf 

ottengo il seguente messaggio:

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

Inizialmente pensavo che il disallineamento tra il mio sistema host a 64 bit e il 32-bit GNU Make non dovrebbe essere un problema, ma per eliminare il mio dubbio ho trovato un file Make GNU a 64 bit (link rimosso a causa del limite) anche se non sono sicuro della sua integrità. In ogni caso, entrambi i file GNU Make producono lo stesso risultato quando si tenta di eseguire il programma sul BBB.

Dopo aver esaminato più post ho scoperto gli strumenti "readelf", "strace" e "stringhe", che hanno prodotto i seguenti output.

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 +++ 

Strings:

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! 

Ho cercato attraverso il mio BeagelBoneBlack per il 4 condiviso file di libreria indicate dalla funzione “readelf” e trovato che sono in realtà presenti. Il problema è comunque che alcuni di questi file si trovano nella directory usr/lib/arm-linux-gnueabihf/mentre altri si trovano nella directory/lib/arm-linux-gnueabihf #. Per risolvere questo problema ho creato collegamenti simbolici ai file non trovati nella directory/usr/lib/arm-linux-gnueabihf /. Questo ancora non ha risolto il problema. Così ho creato collegamenti simbolici a file non trovati nella directory/lib/arm-linux-gnueabihf /. Ancora una volta, nessuna fortuna.

C'è un modo per verificare quale directory viene utilizzata durante l'esecuzione? Cos'altro potrebbe mancare dal file Test6.elf? Sono in perdita al momento. Qualsiasi consiglio o guida sarebbe molto apprezzato! Saluti!

P.S. Sono anche riuscito a verificare GLIBCXX_3.4, GLIBC_2.4 e GCC_3.5 come mostrato di seguito, ma ancora una volta, alcuni di questi si riferiscono ai file in/usr/lib/arm-linux-gnueabihf altri si trovano in/lib/arm-linux-gnueabihf. Grazie ancora!

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 

E, infine, ecco il programma "Ciao ARM World"

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

destro su! Quindi ho funzionato. Ecco i miei passi, si spera siano sani e non mi causeranno problemi in futuro.

1. Da this post, ho cercato di scoprire dove la Test6.elf aspettava di trovare il loader di Linux per le librerie collegate dinamicamente. Questo prodotto:

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

2. ho controllato la mia cartella /lib e abbastanza sicuro il file ld-linux.so.3 mancava. Invece ho trovato nella cartella /lib/arm-linux-gnueabihf/

3. così ho creato un link simbolico nella cartella/lib tramite:

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

E boom! Funziona. Quello che trovo ancora strana però è che il ldd ./Test6.elf restituisce ancora:

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

C'è una buona ragione per questo, o si tratta in qualche modo normale? - Non mi sembra giusto.

Ho anche notato che le mie attuali impostazioni del compilatore (e quindi toolchain) per Float ABI sono impostate su soft, eppure il mio BeagleBoneBlack sta eseguendo arm-linux-gnueabihf - hard float. Questo mi causerà problemi in futuro? Dovrei essere alla ricerca di una diversa toolchain?

Cheers!

Answer 2

Avevo una situazione simile con una libreria chiamata "ibstdC++. So.6". Sviluppo in Eclipse su Ubuntu 14.04 e distribuito su beaglebone con Debian. Non ho mai avuto questo problema in precedenza quando ho usato sviluppato su Eclipse Ubuntu 12.04 e distribuito su Amstrong.

Il modo in cui risolvo il problema era la lettura delle anwsers sopra e cosa ho fatto ho impostato il mio cross-compiler su arm-linux-gnueabihf-g ++. Sembra che la libreria che mi mancava fosse inclusa solo nella versione fluttuante del compilatore e non nel soft floating. Modificare l'impostazione del cross-compiler su Eclipse e risolvere il problema.