发行版提供交叉编译器与自定义构建的 gcc [英] Distro provided cross compiler vs custom built gcc
问题描述
我打算为Raspberry Pi交叉编译，基本上是一台小型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 提供的交叉编译器 arm-elf-gcc-base 和 arm-elf-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.
可以使用股票发行版提供的交叉编译器在通用内核和应用程序中构建 Raspberry Pi 或 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?
更一般的问题，什么一般用例要求自定义 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.
推荐答案
当开发人员谈论为与他们自己的(主机)不同的机器(目标)构建软件(交叉编译)时，他们使用术语toolchain 描述构建二进制文件所需的工具集.那是因为当您需要构建可执行二进制文件时，您需要的不仅仅是编译器.
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 和多个操作系统级配置(例如页面大小)和数据结构(例如时间结构)，您需要一组标准的库，并且这些库需要了解目标上的内核.
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 架构.架构可以向后兼容，但工具链本质上是二进制的，并且针对特定架构.默认情况下，您可以拥有最广泛的架构，但对于已经受到限制的环境(嵌入式设备)而言，这不会太有成效.如果您拥有最新的架构，那么它对于基于旧架构的目标将没有用处.
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.
这篇关于发行版提供交叉编译器与自定义构建的 gcc的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
