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

问题描述

在编写依赖于 CPU 架构的软件时，例如在 x86 上运行的 C 代码或在 ARM cpus 上运行的 C 代码.通常有两种方法可以编译此代码，或者交叉编译到 ARM CPU 架构(例如，如果您正在 x86 系统上开发)，或者将您的代码复制到本机架构 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 spin……当然，由 Red Hat 支持的项目可以访问一些运行 x86 cpus 的强大构建服务器这可以在 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) 如果我正在编译一些具有它使用的第三方库的目标软件，那么在本机平台上构建、部署然后使用它们来构建我的目标可能会更容易；我不想处理这些的交叉编译构建，因为其中一半的构建过程是由疯狂的猴子编写的，这使得交叉编译它们变得很痛苦.

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屋！