发行版提供了交叉编译VS定制GCC [英] Distro provided cross compiler vs custom built gcc
问题描述
我打算交叉编译为树莓派，基本上是一个小型的ARM计算机。主机将运行的Arch Linux的i686的框。
I intend to cross compile for Raspberry Pi, basically a small ARM computer. The host will be an i686 box running Arch Linux.
我的第一直觉是使用的Arch Linux提供的交叉编译器，臂ELF-GCC-基地和手臂小精灵 - binutils的。然而，每一个wiki和后我读似乎使用自定义的GCC编译的一些版本。他们似乎花显著时间料理自己的gcc。问题是，他们从来没有说为什么过来他人使用GCC是很重要的。
My first instinct is to use cross compiler provided by Arch Linux, arm-elf-gcc-base and arm-elf-binutils. However, every wiki and post I read seems to use some version of custom gcc build. They seem to spend significant time on cooking their own gcc. Problem is that they never say WHY it is important to use their gcc over another.
-
能否提供股票发行的交叉编译器可用于建筑物树莓派或ARM一般的内核和应用程序？
Can stock distro provided cross compilers be used for building Raspberry Pi or ARM in general kernels and apps?
是否需要对ARM架构的多个编译器？如果是这样，为什么，因为单一的GCC可以支持所有x86变种？
Is it necessary to have multiple compilers for ARM architecture? If so, why, since single gcc can support all x86 variants?
如果2），那么我怎么能演绎出什么样的目标子集由GCC的特定版本的支持？
If 2), then how can I deduce what target subset is supported by a particular version of gcc?
更普遍的问题，一般有什么用例呼吁海湾合作委员会自建立？
More general question, what general use cases call for custom gcc build?
请像技术，你可以，我想知道为什么以及如何。
Please be as technical as you can, I'd like to know WHY as well as how.
推荐答案
当开发人员谈论构建软件（交叉编译），用于在不同的机器（目标）相比，他们自己的（主机），他们使用术语工具链来形容一套必要建立二进制文件的工具。这是因为当你需要建立一个可执行的二进制，你需要比一个编译器的更多。
When developers talk about building software (cross compiling) for a different machine (target) compared to their own (host) they use the term toolchain to describe the set of tools necessary to build binary files. That's because when you need to build an executable binary, you need more than a compiler.
您需要例程（的crt0.o ）根据初始化运行操作系统和标准库的要求。你需要一套标准库和这些库需要知道目标内核因为系统调用API和多个OS级配置指标（如页面大小）和数据结构指标（如时间结构）。
You need routines (crt0.o) to initialize runtime according to requirements of operating system and standard libraries. You need standard set of libraries and those libraries need to be aware of the kernel on target because of the system calls API and several os level configurations (f.e. page size) and data structures (f.e. time structures).
在硬件方面，也有不同的ARM架构。架构可以向下兼容，但工具链本质上是二进制的，并针对特定的架构。您可以在默认情况下最wides $ P $垫结构但不会是一个已经约束环境（嵌入式设备）也取得丰硕成果。如果您有最新的架构，那么就不会是对老年人架构的目标是有用的。
On the hardware side, there are different set of ARM architectures. Architectures can be backward compatible but a toolchain by nature is binary and targeted for a specific architecture. You can have the most widespread architecture by default but then that won't be too fruitful for an already constraint environment (embedded device). If you have the latest architecture, then it won't be useful for older architecture based targets.
当你建立你的主机主机上的二进制文件，编译器可以从它自己的环境中查找所需的所有位，或者使用什么是主机上的 - 所以大多数的上述资料是不可见的开发商。然而，当您为不同的目标比你的主机类型，工具链必须了解硬件，操作系统和标准库的细节。你告诉这些为工具链...通过根据这可能需要引导某种程度的那些细节构建它的方式。 （或者你可以通过广泛的一套工具链是否支持/内置它的参数做到这一点。）
When you build a binary on your host for your host, compiler can look up all the necessary bits from its own environment or use what's on the host - so most of the above details are invisible to developer. However when you build for a different target than your host type, toolchain must know about hardware, os and standard library details. The way you tell these to toolchain is... by building it according to those details which might require some level of bootstrapping. (or you can do this via extensive set of parameters if toolchain supports / built for it.)
所以，当有一个通用的（股票）交叉编译工具链，它已经有一些具体的目标设定，并且可能无法满足您的要求。请参阅本最近问题有关的例子在Ubuntu的情况。
So when there is a generic (stock) cross compile toolchain, it has already some target specifics set and that might not meet your requirements. Please see this recent question about the situation on Ubuntu for an example.
这篇关于发行版提供了交叉编译VS定制GCC的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
