从Windows交叉编译GNU ARM（BeagleBoneBlack）。* .elf上的运行时错误：“没有这样的文件或目录”【JAVA教程】

概述从Windows交叉编译GNU ARM（BeagleBoneBlack）。 * .elf上的运行时错误：“没有这样的文件或目录”

我正处于开发BeagleBone Black的无人机飞行控制器的（非常）早期阶段。 我应该提到，在BBB，linux和embedded式系统方面，我是新手。我的学术重点是控制理论 – 这是我第一次尝试在Matlab仿真之外进行实践。 我目前的系统如下：

主机 – > windows 8.1 x64运行Eclipse Luna（4.4.0）

目标 – > BeagleBone黑色rev。 B运行Ubuntu 13.10

目标信息

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

目标gcc版本

uclinux libbzip2交叉编译时reloctypes错误

专用的交叉编译开源软件的方式

在windows上交叉编译？

用于win32-g ++平台的qmake生成的Makefile包含了unix命令

arm-linux-gnu-gcc致命错误：stdio.h：没有这样的文件或目录

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)

我已经安装了Sourcery Codebench lite工具链，并使用GNU Make文件 。 我已经根据Michael Jantz提供的教学vIDeo设置了Eclipse环境（由于受到限制，链接被删除 – 如果感兴趣的search“YouTube上的交叉编译和远程浏览BeagleBone”）进行了一些小的调整，以使其运行在我的系统。 这些调整主要包括删除“–specs = rdimon.specs”和“-lrdimon”链接标志，因为在编译时我总是收到“没有这样的文件或目录”。 有了这两个标志删除简单的“你好ARM世界”程序编译没有任何问题。

将编译的ELF文件传输到BeagleBone后，通过以下方式设置权限和可执行标志：

chmod ugo-x Test6.elf

并通过以下方式运行：

./Test6.elf

我收到以下消息：

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

我最初认为我的64位主机系统和32位GNU Make之间的不匹配不应该是一个问题，但为了消除我的疑问，我find了一个64位的GNU Make文件（由于限制，链接被删除了）不知道它的完整性。 在任何情况下，当试图在BBB上执行程序时，两个GNU Make文件都会产生相同的结果。

看过几个post后，我发现了“readelf”，“strace”和“strings”工具，这些工具产生了以下输出。

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

string：

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!

我通过BeagelBoneBlacksearch了从“readelf”函数中指出的4个共享库文件，发现它们实际上是存在的。 然而问题是，其中一些文件可以在usr / lib / arm-linux-gnueabihf /目录中find，而另外一些则可以在/ lib / arm-linux-gnueabihf＃目录下find。 为了解决这个问题，我创build了在/ usr / lib / arm-linux-gnueabihf /目录中找不到的文件的符号链接。 这仍然没有解决问题。 所以我创build了在/ lib / arm-linux-gnueabihf /目录中找不到的文件的符号链接。 再次，没有运气。

有没有办法来检查执行中使用哪个目录？ Test6.elf文件还有什么可能丢失的？ 我目前处于亏损状态。 任何意见或指导将不胜感激！ 干杯!

PS我还设法检查了GliBCXX_3.4，GliBC_2.4和GCC_3.5，如下所示，但其中一些属于/ usr / lib / arm-linux-gnueabihf中的文件，这些文件位于/ lib / ARM-linux的gnueabihf。 再次感谢！

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

最后，这是“Hello 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; }

使用mxe在linux上进行交叉编译 – GSL链接？

交叉编译的libical

交叉编译C windows libcurl在Ubuntu上没有正确链接

为QNX 6.6.0 armle v7交叉编译perl

我如何交叉编译一个QT应用程序的imx6？

对！ 所以我有它的工作。 这是我的步骤，希望他们是健全的，不会在未来导致我的问题。

从这篇文章中 ，我试图找出Test6的预期位置，找到动态链接库的linux加载器。 这产生了：

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

我检查了我的/lib文件夹，果然ld-linux.so.3文件丢失了。 相反，我发现它在/lib/arm-linux-gnueabihf/文件夹中

所以我通过以下方式在/ lib文件夹中创建了一个符号链接：

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

和繁荣！ 有用。 我仍然觉得奇怪的是， ldd ./Test6.elf仍然返回：

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

这是有一个很好的理由，还是这是正常的？ – 这对我来说不太合适。

我还注意到，我目前的float ABI的编译器设置（以及工具链）设置为soft，但是我的BeagleBoneBlack运行的是arm-linux-gnueabihf – hard float。 这会在未来造成我的问题吗？ 我应该寻找一个不同的工具链？

干杯!

我和一个名为“ibstdc ++。so.6”的库有类似的情况。 我在Ubuntu 14.04上使用Eclipse进行开发，并在Debian上部署Beaglebone。 当我使用Eclipse Ubuntu 12.04开发并在Amstrong上部署时，我从未遇到过这个问题。

我解决这个问题的方法是读上面的anwsers，我做了什么，我把交叉编译器设置为arm-linux-gnueabihf-g ++。 似乎我缺少的库只是包含在编译器的硬浮动版本中，而不是软浮动版本。 更改Eclipse上的交叉编译器设置并解决问题。

总结

以上是内存溢出为你收集整理的从Windows交叉编译GNU ARM（BeagleBoneBlack）。 * .elf上的运行时错误：“没有这样的文件或目录”全部内容，希望文章能够帮你解决从Windows交叉编译GNU ARM（BeagleBoneBlack）。 * .elf上的运行时错误：“没有这样的文件或目录”所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。