CPU Arch 的交叉编译或本地编译 [英] Cross Compile or Compile Native for CPU Arch

问题描述

编写依赖于 CPU 架构的软件时，例如在 x86 上运行的 C 代码或在 ARM cpu 上运行的 C 代码.通常有两种方法可以编译此代码，交叉编译到 ARM CPU arch(例如，如果您在 x86 系统上开发)或将您的代码复制到本机 arch cpu 系统并天真地编译它.

When writing software that is CPU arch dependent, such as C code running on x86 or C code running on ARM cpus. There generally is two ways to go about compiling this code, either Cross-Compile to the ARM CPU arch (if you're developing on an x86 system for example) or copy your code to a native arch cpu system and compile it naively.

我想知道本机方法与交叉编译方法相比是否有好处?我注意到 Fedora ARM 团队正在使用一个由慢/低功耗 ARM 设备组成的构建服务器集群来天真地"编译他们的 Fedora ARM 版本……当然，由 Red Hat 支持的项目可以访问一些运行 x86 cpu 的强大构建服务器这可以在 1/2 的时间内完成工作......那么他们为什么选择?交叉编译我的软件是否遗漏了什么?

I'm wondering if there is a benefit to the native approach vs the cross-compile approach? I noticed that the Fedora ARM team is using a build-server cluster of slow/low power ARM devices to "naively" compile their Fedora ARM spin... surely a project backed by Red Hat has access to some powerful build servers running x86 cpus that could get the job done in 1/2 the time... so why their choice? Am I missing something by cross-compiling my software?

推荐答案

从技术上讲，在 .c -> .o -> a.out(或其他)的上下文中交叉编译不会遗漏任何内容；交叉编译器将为您提供与本机编译器相同的二进制文件(尽管有版本等)

No technically you're not missing anything by cross-compiling within the context of .c -> .o -> a.out (or whatever); A cross compiler will give you the same binary as a native compiler (versions etc. notwithstanding)

本机构建的优势"来自编译后测试和管理复杂系统.

The "advantages" of building natively come from post-compile testing and managing complex systems.

1) 如果我可以在编译后快速运行单元测试，我可以快速找到任何错误/问题，这个周期可能比交叉编译周期短；

1) If I can run unit-tests quickly after compiling I can get to any bugs/issues quickly the cycle is presumably shorter than the cross-compiling cycle;

2) 如果我编译的目标软件有它使用的 3rd-party 库，那么在本机平台上构建、部署然后使用它们来构建我的目标可能会更容易；我不想处理那些的交叉编译构建，因为其中一半的构建过程是由疯狂的猴子编写的，这使得交叉编译它们变得很痛苦.

2) if I am compiling some target software that has 3rd-party libraries that it uses, then building, deploying and then using them to build my target would probably be easier on native platform; I don't want to deal with the cross-compile builds of those because half of them have build processes written by crazy monkeys that make cross compiling them a pain.

通常，对于大多数事情，人们会尝试进行基础构建，然后本机编译其余部分.除非我有一个病态的设置，我的交叉编译器非常快速而且我节省的时间值得进行设置以使其余的事情(例如单元测试和依赖项管理)更容易.

Typically for most things one would try to get to a base build and the compile the rest natively. Unless I have a sick set up where my cross compiler is super wicked fast and I the time I save there is worth the set up required to make the rest of the things (such as unit testing and dependencies management) easier.

至少这是我的想法

这篇关于CPU Arch 的交叉编译或本地编译的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！