交叉编译为嵌入式基于ARM-Linux系统

问题描述

我尝试编译一些C code为嵌入式（自定义），基于ARM-Linux系统。我建立了一个Ubuntu的虚拟机与名为ARM的Linux的gnueabi-GCC-4.4，因为它看起来像什么，我需要一个交叉编译器。现在，当我编译我的code这个GCC，它会产生一个二进制是这样的：

  $文件TEST1
测试1：ELF 32位LSB的可执行文件，ARM版本1（SYSV），动态链接
（使用共享库），为GNU / Linux 2.6.31，
BuildID [SHA1] = 0x51b8d560584735be87adbfb60008d33b11fe5f07，不可剥离
 

当我尝试运行嵌入式Linux此二进制，我得到

  $ ./test1
-SH：./test1：未找到
 

权限就足够了。我只能想象，什么是错的二进制格式，所以我看了一些二进制工作作为参考：

  $文件referenceBinary
referenceBinary：ELF 32位LSB的可执行文件，ARM，版本1，动态链接
（使用共享库），剥去
 

我看到有一定的差异，但我没有足够的知识来推导正是我需要解决，我怎么能解决这个问题。有人能解释其中的区别是至关重要的？

我看了一下另一件事是依赖关系：

  $ LDD TEST1
    libc.so.6的= GT;未找到（00000000）
    /lib/ld-linux.so.3 =＆GT; /lib/ld-linux.so.3（00000000）
 

（有趣的是，这部作品在目标系统上虽然不能执行二进制）嵌入式系统只有一个 libc.so.0 可用。我想我需要告诉编译器的libc版本我想对联系，但据我所知，GCC只是链接反对它自带的版本，这是正确的？我能做些什么呢？

编辑：这是我使用的Makefile：

  CC =的/ usr / bin中/ ARM-Linux的gnueabi-GCC-4.4
STRIP =的/ usr / bin中/ ARM-Linux的gnueabi带钢
CFLAGS = -I的/ usr / ARM-Linux的gnueabi /包括
LDFLAGS = -nostdlib
LDLIBS = .. / libc.so.0SRCS = test1.c
OBJS = $（SUBST .C，即.o，$（SRCS））所有：TEST1测试1：$（OBJS）
    $（CC）$（LDFLAGS）-O主要$（OBJS）$（LDLIBS）
    $（STRIP）主取决于：的.depend的.depend：$（SRCS）
    RM -f ./.depend
    $（CC）$（CFLAGS）$ -MM ^＆GT;方式＆gt; ./依赖;清洁：
    RM -f $（OBJS）包括的.depend
 

解决方案

什么你应该做的是安装 libc6的嵌入式系统。读<一个href=\"http://www.linuxquestions.org/questions/linux-embedded-78/compile-$c$c-for-arm-processor-703336/\"相对=nofollow>有关类似问题的这个线程。在岗位＃5的解决方案是安装：

  libc6_2.3.6.ds1-13etch9_arm.deb
Linux的内核headers_2.6.18-7_arm.deb
libc6的-dev_2.3.6.ds1-13etch9_arm.deb
 

您另一种选择是让的libc 从嵌入式系统到你的虚拟机，然后将其传递给 GCC 连接​​器，并使用 -static 选项。

此溶液也与上述螺纹提及。了解更多关于静态链接。

其他的事情尝试：

在他们建议删除 = -mabi APCS-GNU 从makefile标志，如果你使用的。

<一个href=\"http://balau82.word$p$pss.com/2010/12/05/using-ubuntu-arm-cross-compiler-for-bare-metal-programming/\"相对=nofollow>这篇文章表明feedint GCC如果你在命令行编译 -nostdlib 标记。

或者你可以切换到使用臂无 - EABI - 海合会编译器。在这个参考文献可以发现。

I try to compile some C code for an embedded (custom) ARM-based Linux system. I set up an Ubuntu VM with a cross-compiler named arm-linux-gnueabi-gcc-4.4 because it looked like what I needed. Now when I compile my code with this gcc, it produces a binary like this:

$ file test1
test1: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked
(uses shared libs), for GNU/Linux 2.6.31,
BuildID[sha1]=0x51b8d560584735be87adbfb60008d33b11fe5f07, not stripped

When I try to run this binary on the embedded Linux, I get

$ ./test1
-sh: ./test1: not found

Permissions are sufficient. I can only imagine that something's wrong with the binary format, so I looked at some working binary as reference:

$ file referenceBinary
referenceBinary: ELF 32-bit LSB executable, ARM, version 1, dynamically linked
(uses shared libs), stripped

I see that there are some differences, but I do not have the knowledge to derive what exactly I need to fix and how I can fix that. Can someone explain which difference is critical?

Another thing I looked at are the dependencies:

$ ldd test1
    libc.so.6 => not found (0x00000000)
    /lib/ld-linux.so.3 => /lib/ld-linux.so.3 (0x00000000)

(Interestingly, this works on the target system although it cannot execute the binary.) The embedded system only has a libc.so.0 available. I guess I need to tell the compiler the libc version I want to link against, but as I understand it, gcc just links against the version it comes with, is this correct? What can I do about it?

Edit: Here's the Makefile I use:

CC=/usr/bin/arm-linux-gnueabi-gcc-4.4
STRIP=/usr/bin/arm-linux-gnueabi-strip
CFLAGS=-I/usr/arm-linux-gnueabi/include
LDFLAGS=-nostdlib
LDLIBS=../libc.so.0

SRCS=test1.c
OBJS=$(subst .c,.o,$(SRCS))

all: test1

test1: $(OBJS)
    $(CC) $(LDFLAGS) -o main $(OBJS) $(LDLIBS)
    $(STRIP) main

depend: .depend

.depend: $(SRCS)
    rm -f ./.depend
    $(CC) $(CFLAGS) -MM $^>>./.depend;

clean:
    rm -f $(OBJS)

include .depend

解决方案

What you should probably do is to install libc6 on the embedded system. Read this thread about a similar problem. The solution in post #5 was to install:

libc6_2.3.6.ds1-13etch9_arm.deb
linux-kernel-headers_2.6.18-7_arm.deb
libc6-dev_2.3.6.ds1-13etch9_arm.deb

Your other option is to get the libc from the embedded system onto your VM and then pass it to the gcc linker and use the -static option.

This solution was also mentioned in the above thread. Read more about static linking here.

Other things to try:

In this thread they suggest removing the -mabi=apcs-gnu flag from your makefile if you're using one.

This article suggests feedint gcc the -nostdlib flag if you're compiling from the command line.

Or you could switch to using the arm-none-eabi-gcc compiler. References on this can be found here and here.

这篇关于交叉编译为嵌入式基于ARM-Linux系统的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！