来自Windows的交叉编译GNU ARM(BeagleBoneBlack)。 * .elf上的运行时错误:"没有这样的文件或目录"

时间:2014-07-03 01:09:29

标签: c++ linux cross-compiling beagleboneblack toolchain

我在BeagleBone Black上开发无人机飞行控制器的(非常)早期阶段。我应该提到我在BBB,Linux和嵌入式系统方面相当新手。我的学术重点一直是控制理论 - 这是我第一次尝试在Matlab仿真之外的实际实现。我目前的系统如下:

宿主>运行Eclipse Luna的Windows 8.1 x64(4.4.0)
目标 - > BeagleBone Black 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版本

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 file。我根据Michael Jantz提供的教学视频设置了Eclipse环境(由于限制而删除了链接 - 如果感兴趣的搜索" BeagleBone的交叉编译和远程浏览"在YouTube上),并进行了一些小的调整让它在我的系统上运行。这些调整主要包括删除" - specs = rdimon.specs"和" -lrdimon"链接标志,因为我一直得到一个"没有这样的文件或目录"编译时通过这两个标志删除了简单的" Hello ARM World"程序编译没有任何问题。

将已编译的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之间的不匹配应该不是问题,但为了消除我的疑问我找到了64位GNU Make文件(由于限制而删除了链接)虽然我不确定它的完整性。在任何情况下,当尝试在BBB上执行程序时,两个GNU Make文件都会产生相同的结果。

在浏览了几篇文章之后,我发现了“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 +++

的字符串:

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!

我在BeagelBoneBlack中搜索了“readelf”函数指示的4个共享库文件,发现它们实际存在。但问题是,其中一些文件位于usr / lib / arm-linux-gnueabihf /目录中,而其他文件位于/ lib / arm-linux-gnueabihf#目录中。为了解决这个问题,我创建了指向/ usr / lib / arm-linux-gnueabihf /目录中找不到的文件的符号链接。这仍然没有解决问题。所以我创建了符号链接到/ lib / arm-linux-gnueabihf /目录中找不到的文件。再一次,没有运气。

有没有办法检查执行时使用的目录? Test6.elf文件中可能还缺少什么?我此刻不知所措。任何建议或指导将不胜感激!干杯!

P.S。我还设法检查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

最后,在这里,#ARM; 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;
}

2 个答案:

答案 0 :(得分:3)

正确!所以我已经开始工作了。这是我的步骤,希望它们是合理的,不会在将来引起我的问​​题。

  1. this post开始,我试图找出Test6.elf期望为动态链接库找到linux加载器的位置。这产生了:

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

  2. 我检查了我的/lib文件夹,确定ld-linux.so.3文件丢失了。相反,我在/lib/arm-linux-gnueabihf/文件夹

  3. 中找到了它
  4. 所以我通过以下方法在/ lib文件夹中创建了一个符号链接:

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

  5. 繁荣!有用。然而,我仍然觉得奇怪的是ldd ./Test6.elf仍然会返回:

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

    这是否有充分的理由,或者这是否正常? - 这对我来说似乎不对。

    我还注意到我将Float ABI的当前编译器设置(以及工具链)设置为soft,但我的BeagleBoneBlack正在运行arm-linux-gnueabihf - hard float。这会不会给我带来问题?我应该寻找不同的工具链吗?

    干杯!

答案 1 :(得分:0)

我遇到了一个名为&#39; ibstdc ++。so.6&#39;的类似情况。我在Ubuntu 14.04上使用Eclipse进行开发,并使用Debian在beaglebone上进行部署。我之前从未在Eclipse Ubuntu 12.04上开发并在Amstrong上部署时遇到过这个问题。

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