本文为译文，点击
此处查看原文。
1. 介绍
本文档将指导您选择正确的 Clang 选项，以便将代码交叉编译到不同的体系结构。它假定您已经知道如何为主机体系结构编译相关代码，并且知道如何选择附加的include和库路径。
然而，这个文档不是一个“如何做”的文档，也不会帮助您设置build系统或Makefiles，也不会帮助您选择正确的 CMake 选项，等等。此外，它没有涵盖所有可能的选项，也没有包含特定架构的特定示例。对于一个具体的例子，交叉编译LLVM本身的说明可能会很有趣。
阅读本文之后，您应该熟悉与交叉编译相关的主要问题，以及 Clang 为执行交叉编译提供了哪些主要编译器选项。
2. 交叉编译问题(Cross compilation issues)
在 GCC 世界中，每个主机/目标(host/target)组合都有自己的一组二进制文件、头文件、库等。因此，通常很容易下载一个包含所有文件的包，解压缩到一个目录，然后将build系统指向该编译器，该编译器将知道其位置，并在编译代码时找到所需的所有内容。
另一方面，Clang/LLVM 本质上是一个交叉编译器，这意味着一组程序可以通过设置-target选项编译到所有目标。对于希望编译到不同平台和体系结构的程序员，对于只需要维护一个build系统的编译器开发人员，对于OS发布，只需要一组main包，这使得编译变得容易得多。
但是，与任何交叉编译器一样，考虑到不同体系结构、操作系统和选项的复杂性，要找到头文件、库或binutils来生成目标特定的代码并不总是那么容易。因此，您需要指定选项(options)来帮助 Clang 了解您要编译的目标、工具的位置等等。
另一个问题是编译器只附带标准库(如compiler-rt、libcxx、libgcc、libm等)，因此您必须找到并提供给构建系统，以及构建软件所需的每个特定于您的目标(target)的其他库。仅仅安装主机(host)的库是不够的。
最后，并不是所有的工具链(toolchains)都是相同的，因此，并不是每个 Clang 选项都能神奇地工作。有些选项，比如--sysroot(它可以有效地更改头文件和库的逻辑根)，假设所有二进制文件和库都在同一个目录中，当发行版的包管理安装了交叉编译器时，这可能不是真的。因此，对于每个特定的情况，您可以使用多个选项，并且在大多数情况下，您最终将手动设置include paths (-I)和library paths (-L)
综上所述，不同的工具链可能：
- 特定于 host/target 或更灵活
- 放在一个目录中，或者分散在整个系统中
- 默认情况下有不同的库集和头文件集
- 需要特殊的选项，这是您的构建系统无法自己解决的
3. Clang中的一般交叉编译选项(General Cross-Compilation Options in Clang)
3.1 Target Triple
基本选项是定义目标体系结构。为此，使用-target <triple>。如果不指定目标，CPU 名称将不匹配（因为 Clang 假设host triple），编译将继续进行，为主机平台创建代码，稍后在汇编或链接时代码将中断。
triple 的一般格式为<arch><sub>-<vendor>-<sys>-<abi>，其中：
-
arch = x86_64、i386、arm、thumb、mips等。
- sub = v5, v6m, v7a, v7m等。
- vendor = pc, apple, nvidia, ibm,等。
- sys = none, linux, win32, darwin, cuda等。
- abi = eabi, gnu, android, macho, elf等。
当然，sub体系结构选项对于它们自己的体系结构是可用的，所以“x86v7a”没有意义。只有在发生相关更改时才需要指定vendor，例如在PC和Apple之间。大多数情况下，可以忽略它(并且未知)，这将为指定的体系结构设置默认值。system名称通常是OS (linux, darwin)，但也可以像裸金属“none”一样特殊。
当一个参数不重要时，可以省略它，或者您可以选择unknown并使用缺省值。如果您选择一个 Clang 不知道的参数，比如blerg，它将忽略并假设未知，这并不总是需要的，所以要小心。
最后，ABI选项将选择默认的CPU/FPU，定义代码的特定行为(pc、扩展)，并选择正确的库调用，等等。
3.2 CPU、FPU、ABI
一旦指定了目标，就到了选择要编译到的硬件的时候了。对于每种体系结构，都会选择一组默认的CPU/FPU/ABI，因此您几乎总是必须通过flag更改它。
典型的flag包括:
-
-mcpu=<cpu-name>，如x86-64, swift, cortex-a15
-mfpu=<fpu-name>，如SSE3, NEON，控制FP单元可用
-
-mfloat-abi=<fabi>，如控制浮点寄存器的软、硬件
默认值通常是公分母，因此Clang不会生成中断的代码。但这也意味着您无法为特定的硬件获得最佳代码，这可能意味着速度比您预期的要慢几个数量级。
例如，如果您的目标是arm-none-eabi，那么默认的CPU将是使用软浮点数的arm7tdmi，这在现代内核上是非常慢的，而如果您的三元组是armv7a-none-eabi，那么它将是带NEON的Cortex-A8，但是仍然使用软浮点数，这要好得多，但是仍然不是很好。
3.3 工具链选项
控制对交叉编译器的访问有三个主要选项:-sysroot、-I和-L。最后两个是众所周知的，但是对于特定于目标的附加库和头文件来说，它们尤其重要。
有两种主要的方式获得一个交叉编译器:
- 当您将交叉编译器从zip文件解压缩到目录中时，必须使用
--sysroot=<path>。path是您解压缩文件的根目录，Clang 将查找其中包含的目录bin、lib。
在这种情况下，您的设置应该已经基本完成(如果不需要额外的头文件或库)，因为Clang将在其中找到它需要的所有二进制文件(汇编器、链接器等)。
- 当您通过包管理器安装(现代Linux发行版有交叉编译器包可用)时，请确保您设置的目标triple也是交叉编译器工具链的前缀。
在本例中，Clang 将找到其他二进制文件(汇编器、链接器)，但并不总是在目标头文件和库所在的位置。人们经常在Clang 中添加特定于系统的线索，但是随着事情的变化，它很可能不会发现，而不是相反。
因此，在这里，如果手动指定include/library目录(通过-I和-L)，将会安全得多。
4. 特定目标的库(Target-Specific Libraries)
作为构建的一部分编译的所有库都将被交叉编译到目标，构建系统可能会在正确的位置找到它们。但是，通常检查的所有依赖项(如libxml或libz等)都将与主机平台匹配，而不是与目标平台匹配。
因此，如果构建系统没有意识到您想交叉编译代码，那么它将错误地获得每个依赖项，并且编译将在构建期间失败，而不是在配置期间。
此外，查找目标的库并不像查找主机那么容易。大多数OS的包中没有多少跨库可用，所以您必须从源代码交叉编译它们，或者下载目标平台的包，提取库和头文件，将它们放在特定的目录中，并添加-I和-L指向它们。
此外，一些库对不同的目标具有不同的依赖关系，因此，在主机中查找依赖关系的配置工具可能会将目标平台的列表弄错。这意味着在设置自己的库路径时，您的构建的配置可能会出错，您必须通过附加标志(configure、Make、CMake等)来扩充它。
5. Multilibs
当您希望交叉编译到多个配置时，例如hard-float-ARM和soft-float-ARM，您必须拥有库的多个副本和(可能的)头文件。
有些Linux发行版支持Multilib，用一种更简单的方式为你处理，但是如果你不小心，例如，忘记指定-ccc-gcc-name armv7l-linux-gnueabihf-gcc(使用hard-float)，Clang将选择armv7l-linux-gnueabi-ld(使用soft-float)，并且将会发生链接器错误。
如果您正在为不同的ABIs(如gnueabi和androideabi)编译，甚至可能链接并运行，但会产生运行时错误，这将更加难以跟踪和修复，那么情况也是一样的。
