Linux 交叉编译简介

主机，目标，交叉编译器

主机与目标

编译器是将源代码转换为可执行代码的程序。像所有程序一样，编译器运行在特定类型的计算机上，输出的新程序也运行在特定类型的计算机上。

运行编译器的计算机称为主机，运行新程序的计算机称为目标。当主机和目标是同一类型的机器时，编译器是本机编译器。当宿主和目标不同时，编译器是 交叉编译器。

为什么要交叉编译？

某些设备构建程序的PC，用户可以获得适当的目标硬件（或模拟器），启动 Linux Release版，在该环境中进行本地编译。这是一种有效的方法（在处理 Mac Mini时甚至可能是一个好主意），但对于 linksys 路由器，或 iPod，有一些突出的缺点：

• 速度- 目标平台通常比主机慢一个数量级或更多。大多数专用嵌入式硬件是为低成本和低功耗而设计的，而不是高性能。由于在高性能桌面硬件上运行，现代模拟器（如 qemu）实际上比模拟的许多现实世界的硬件要快。
• 性能- 编译非常耗费资源。目标平台通常没有台式机GB 内存和数百 GB 磁盘空间；甚至可能没有资源来构建“hello world”，更不用说大而复杂的包了。
• 可用性-未运行过的硬件平台上运行 Linux，需要交叉编译器。即使在 Arm 或 Mips 等历史悠久的平台上，给定目标找到最新的全功能预构建本机环境很困难。如果平台通常不用作开发工作站，可能没有现成的最新预构建Release版，如果有，则可能已经过时。如果必须先为目标构建Release版，才能在目标上进行构建，无论如何都将返回交叉编译。
• 灵活性- 功能齐全的 Linux Release版，由数百个软件包组成，但交叉编译环境可以从大多数方面依赖于主机的现有Release版。交叉编译的重点是构建要部署的目标包，不是花时间获取在目标系统上运行的仅构建先决条件。
• 方便-用户界面不友好，debug构建中断不方便。从 CD 安装到没有 CD-ROM 驱动器的机器上，在测试环境和开发环境之间来回重新启动。

 为什么交叉编译很难？

便携式本机编译很困难。

大多数程序是在 x86 硬件上开发的，在本地编译的。交叉编译会遇到两种类型的问题：程序本身的问题和构建系统的问题。

第一类问题会影响所有非 x86 目标，包括本机和交叉构建。大多数程序对运行的机器类型做出假设，必须与相关平台匹配，否则程序将无法运行。常见的假设包括：

• Word size - 将指针复制到 int 可能会在 64 位平台上丢失数据，通过乘以 4 而不是 sizeof(long) ，确定 malloc 的大小不好。整数溢出导致细微安全漏洞，ala“if (x+y < size) memset(src+x,0,y);”，当 x=1000 时，在 32 位硬件上产生 4 GB 的 memset y=0xFFFFFFF0...
• Endianness - 不同的系统用不同的方式在内部存储二进制数据，从磁盘或网络中，读取 int 或 float 数据可能需要转换。
• Alignment - 某些平台（例如 arm）只能从 4 字节的偶数倍的地址，读取或写入整数，否则出现段错误。处理任意alignment的处理，未alignment的数据都较慢，编译器通常会填充结构alignment变量。将结构视为可以发送到磁盘或通过网络发送的数据块，需要额外的工作确保一致的表示。
• 默认签名- “char”数据类型，默认为有符号或无符号，因平台而异（从编译器到编译器），导致一些非常令人惊讶的错误。简单解决方法是提供一个编译器参数，如“-funsigned-char”，强制默认值为已知值。
• NOMMU - 如果目标平台没有内存管理单元，需要更改几项内容。需要 vfork()，不是 fork()，只有某些类型的 mmap() 工作（共享或只读，但不能在写入时复制），堆栈不会动态增长。

大多数包的目标是在本地编译时可移植，至少会接受补丁，修复提交到适当的开发邮件列表的任何上述问题（NOMMU 问题除外）。

然后是交叉编译。

 除了本机编译的问题外，交叉编译还有其自身的一系列问题：

• 配置问题- 具有单独配置步骤的包（标准 configure/make/make install 的“./configure”部分），通常会测试字节顺序或页面大小等内容，在本机编译时可移植。交叉编译时，这些值在主机系统和目标系统之间不同，在主机系统上运行测试，给出错误的答案。当目标没有该软件包或版本不兼容时，配置检测主机上，是否存在软件包支持。
• HOSTCC vs TARGETCC -构建过程需要编译在主机系统上运行，如上述配置测试，或生成代码的程序（如创建 .h 文件的 C 程序，在main构建期间 #included ）。用目标编译器替换主机编译器，破坏在构建过程中运行库。这样的库需要访问主机和目标编译器，需要说明何时使用。
• 工具链泄漏- 配置不当的交叉编译工具链，将主机系统的一些内容泄漏到已编译的程序中，导致通常易于检测，但难以诊断和纠正的故障。工具链可能 #include 错误的头文件，或在链接时搜索错误的库路径。共享库通常依赖于其它共享库，可能会潜入对主机系统的意外链接时引用。
• 库- 动态链接的程序必须在编译时，访问适当的共享库。目标系统的共享库，需要添加到交叉编译工具链中，以便程序可以链接到。
• 测试- 在本机构建上，开发系统提供了方便的测试环境。交叉编译时，确认“hello world”构建成功，可能需要（至少）配置引导加载程序，内核，根文件系统和共享库。

脚注 1：计算机类型之间最显着的区别是执行程序的处理器，其它差异包括库 ABI（例如 glibc 与 uClibc），具有可配置字节序的机器（arm 与 armeb），或不同模式的机器，可以运行 32 位和 64 位代码（例如 x86 上的 x86-64）。

脚注 2：在构建编译器时，第三种类型称为“加拿大交叉”，一种不在主机系统上运行的交叉编译器。加拿大交叉构建了一个编译器，该编译器在一个目标平台上运行，另一台目标机器生成代码。首先创建从主机到第一个目标的临时交叉编译器，作为第二个目标构建另一个交叉编译器构建这样的外部编译器。第一个交叉编译器的目标成为运行新编译器的主机，第二个目标是新编译器生成输出的平台。这种技术通常用于为目标平台交叉编译新的本机编译器。

脚注 3：现代桌面系统足够快，模拟目标在模拟器下进行本地编译，实际上是一种可行的策略。比交叉编译慢得多，需要为目标查找或生成本机构建环境（无论如何都必须设置交叉编译器），可能会因模拟器和要部署的真实硬件之间的差异崩溃。

脚注 4：交叉编译工具链倾向于为其实用程序的名称加上前缀，ala “armv5l-linux-gcc”。如果简单地称为“gcc”，主机和本机编译器就不能同时在 $PATH 中。

参考链接：

http://landley.net/writing/docs/cross-compiling.html