有关 Rust 交叉编译的一些思路 (仅供参考)

近来, 使用 Rust 语言开发的应用程序, 渐渐融入了开发者以及普通用户的日常生活. 它们不仅出现在我们常用的工作平台上, 不少嵌入式设备或者云服务器上也多见它们的身影.

Rust 是一种需要编译的语言, 且一些 crate 仍需要 C/C++ 的构建环境. 大多数时候, 在 Rust 工具链 (toolchain) 支持的设备上进行原生构建不会遇到什么问题. 而当目标设备的架构, 与构建时使用的设备架构相同时, 直接将构建好的产物发送至目标设备上即可使用.

不止是很多嵌入式设备使用 ARM 架构. 近来, 不少云服务器商也开始提供 ARM64 架构的通用计算平台服务. 如果不是出于构建目的而特意选择较高配置的服务计划, 只是出于部署服务的目的, 则往往不会为这些设备分配太多的性能资源, 进而不足以在其上进行项目的构建. 而作为个人开发者/用户, 往往不一定有相同平台且性能足够的设备进行构建工作, 要为这些设备可以直接执行的二进制文件 (binaries), 就需要进行交叉编译/构建.

编译/构建概念简述

要理解交叉编译/构建, 可以先从可执行程序 (executable) / 二进制文件 (binaries) 的构建开始.

可执行程序里主要包含的是机器可以理解的指令, 由于它们一般先由操作系统加载并执行, 因此还要存储在操作系统所能读取的格式中. 因此, 要 构建 出可以使用的二进制文件, 需要根据源代码, 生成 对应平台 的指令, 并在最后将这些指令以 操作系统所要求 的可执行文件格式进行封装.

当然, 实际中的项目的代码往往繁多, 最终生成的二进制文件可能也不止一个, 意味着代码之间存在复用的情况. 因此, 为了减少重复的编译工作, 以及为了在更改了某些部分的代码后不一定需要重新编译其他的部分, 源代码往往会被分开在不同的文件 (亦即不同的单元) 中进行编译, 最后综合起来形成整体; 项目通常也会使用到来自外部的依赖, 也就是所说的 “软件包” 或者 “(代码) 库”, 这些部分的代码, 并不全都以源代码的形