据我所知,要让gcc在armv5板上编译可执行文件,同时使用我的x86机器编译arm本地gcc,我需要这样的设置:
基于读取跨ng文档这里,我应该使用跨本机设置,但是当我试图使用ct-ng menuconfig启用该设置时,我需要启用:
Paths and misc options -> Try features marked as EXPERIMENTAL实验Toolchain options -> Type (Cross) -> Cross-native (NO CODE!) (EXPERIMENTAL)但是,当然,由于没有代码,跨本地语言无法工作。谷歌让我看到了这和这在邮件列表上的讨论,他们说我应该尝试使用加拿大的构建风格来做这件事,但我有点不知道在交叉台Build System和Host System中使用什么元组和什么东西,或者这是否仍然是考虑这两种讨论已经超过3年的正确方式。
因此,这帖子似乎意味着构建系统和主机系统元组应该是arm-unknown-linux-gnueabi。
要明确的是,我已经能够使用从交叉工作台ng生成的交叉编译器编译和运行可执行文件,现在我希望在那个armv5系统上有一个编译器。
编辑:所以我刚刚将交叉编译器(arm-unknown-linux-gnueabi)添加到Toolchain options -> General toolchain options -> Host system -> Tuple中的元组中,并且能够编译gcc,并让它在arm上执行。示例
我现在只需要修复库的情况,应该是这样的。
发布于 2015-03-28 19:20:52
这个答案是我的原始问题关于交叉编译工具链的一般工作流程的扩展。
我有一个正确的总体想法,您必须使用主机系统元组作为Canadian-Build,arm-unknown-linux-gnueabi交叉编译器是我早些时候做的。请确保将其包含到您的路径中,或者执行一些到/bin的符号链接,或者您想要处理的任何其他操作。
在使用普通HDD的Ubuntu虚拟机中,使用I5-3570k和~2GB的3/4内核进行构建时,我不得不等待大约30分钟。使用SSD可能会大大提高速度。
一旦完成,您应该有一个Crosstools为您创建的输出目录,其中包括ARM体系结构的工具链。您可以通过在任何二进制文件上运行file filename来验证这一点。
现在,对于图书馆的情况,我花了一段时间,并给了一个相当大的混乱。在工具链输出中,应该有一个rootfs文件夹。该文件夹包含您要为其编译的目标的预期根文件系统(在本例中为arm)。您需要从用户复制/lib文件夹和lib文件夹,镜像这个rootfs文件夹的文件夹层次结构。
您可以通过执行objdump -p filename并查看指向所需库的NEEDED条目来验证库的设置是否正确,这些库应该在rootfs中。
如果您使用的是一个基于busybox的rootfs,那么假设您没有静态编译它,那么您可能已经正确地安装了库,因为您需要它们来安装busybox。我首先对busybox进行了静态构建,以确保系统能够引导到shell,然后使用工具链rootfs文件夹中的库进行非静态构建,以便为库提供软启动。一旦我使动态链接的busybox系统正常工作,只需将交叉编译的工具链放到任意位置的rootfs中就足够了(对于我来说是/usr/home/toolchain),在此之后,您应该使用这个工具链,就像x86系统引用路径和符号链接以及您想做的任何事情一样。
https://stackoverflow.com/questions/29201599
复制相似问题