4. 交叉编译工具链搭建与验证
在 Sitara Linux BSP 开发中，交叉编译工具链是连接开发主机与目标板的第一道桥梁。宿主机通常是 x86_64 的 Ubuntu，而目标板是 ARM Cortex-A8/A9/A15 等架构的 Sitara 芯片（如 AM335x、AM437x、AM57xx）。工具链的作用，就是在 x86 主机上生成能在 ARM 上运行的 ELF 可执行文件、内核模块和共享库。本节围绕 SDK 安装、环境变量配置、hello world 交叉编译、ABI 与浮点策略，以及工业场景下的工具链选型展开。
一、SDK 安装与目录结构
TI 为 Sitara 平台提供 Processor SDK Linux，其中包含预构建的工具链。以 AM335x 为例，常见安装包形如 ti-processor-sdk-linux-am335x-evm-08.02.00.24-Linux-x86-Install.bin。安装时赋予可执行权限并运行：
chmod +x ti-processor-sdk-linux-am335x-evm-08.02.00.24-Linux-x86-Install.bin
./ti-processor-sdk-linux-am335x-evm-08.02.00.24-Linux-x86-Install.bin安装完成后，SDK 根目录下会出现 linux-devkit 子目录，工具链位于 linux-devkit/sysroots/x86_64-arago-linux/usr/bin/，目标根文件系统位于 linux-devkit/sysroots/armv7ahf-neon-linux-gnueabi/。这个 sysroot 非常关键，它包含了目标板上的头文件和库，交叉编译时编译器会从这里查找依赖，而不是使用宿主机的 /usr/include。
二、环境变量配置
每次打开终端都手动输入完整路径并不现实，通常通过环境变量脚本完成初始化。SDK 提供了 environment-setup 脚本，执行后会自动设置 CC、CXX、PATH、SDKTARGETSYSROOT 等变量：
source linux-devkit/environment-setup
echo $CC
# arm-linux-gnueabihf-gcc -march=armv7-a -marm -mfpu=neon ...其中 SDKTARGETSYSROOT 指向目标 sysroot，CC 已经带上了架构、浮点等编译选项。建议把 source 命令写入 ~/.bashrc 或单独的 env.sh，避免污染全局环境。验证配置是否生效，可以执行 arm-linux-gnueabihf-gcc -v，观察输出中的 target 是否为 arm-linux-gnueabihf，以及 sysroot 路径是否正确。
三、交叉编译 hello world
编写一个最小示例 hello.c：
#include <stdio.h>
int main(void) {
printf("Hello Sitara ARM!\n");
return 0;
}使用环境变量中的 $CC 编译：
$CC hello.c -o hello
file hello
# hello: ELF 32-bit LSB executable, ARM, EABI5 ...如果 file 输出显示 ARM 架构，说明交叉编译成功。接着把 hello 拷贝到目标板（可通过 NFS、TFTP 或 SD 卡），在目标板串口终端执行 ./hello，看到 Hello Sitara ARM! 即完成闭环验证。若在目标板运行时报 No such file or directory，往往不是文件缺失，而是动态链接器路径不匹配，可用 readelf -l hello | grep interpreter 查看解释器是否为 /lib/ld-linux-armhf.so.3。
四、ABI 与浮点策略
ARM 交叉工具链的命名本身就携带了 ABI 信息。arm-linux-gnueabi 表示使用软浮点 ABI，浮点运算通过软件库模拟；arm-linux-gnueabihf 表示硬浮点 ABI，浮点参数通过 VFP 寄存器传递。两者生成的二进制不兼容，混用会导致链接错误或运行时崩溃。Sitara AM335x 内置 VFPv3 和 NEON，工业场景通常选择 gnueabihf 配合 -mfpu=neon，以发挥硬件浮点和 SIMD 能力。
需要特别注意的是，工具链的浮点 ABI 必须与目标根文件系统中的 C 库一致。如果 SDK 的 sysroot 是 armv7ahf-neon-linux-gnueabi，那么编译时必须使用对应的 gnueabihf 编译器，否则链接 libc.so.6 时会报 ABI 不匹配。判断方法是用 readelf -A 查看 ELF 的 Tag_ABI_VFP_args 属性，值为 VFP registers 即硬浮点。
五、工业场景下的工具链选型对比
工业项目对工具链的要求不仅是“能编译”，还包括长期可维护性、实时性支持和认证需求。常见选择有三类：TI 官方 Processor SDK 工具链、Linaro/Yocto 构建的工具链、以及商业工具链（如 ARM Compiler、IAR）。
| 选型 | 典型版本 | 优势 | 局限 | 适用场景 |
|---|---|---|---|---|
| TI Processor SDK | gcc 9.2 / 11.3 | 与 BSP、内核、U-Boot 版本严格匹配，sysroot 完整 | 版本更新慢，绑定 TI 生态 | AM335x/AM437x 标准工业控制 |
| Yocto/Linaro | gcc 10~13 | 可定制、社区活跃、支持新特性 | 需自行维护 BSP 层，配置复杂 | 多平台复用、长期演进项目 |
| 商业工具链 | ARM Compiler 6 | 优化强、有功能安全认证包 | 授权费用高，生态封闭 | 功能安全 SIL/ASIL 认证场景 |
对于大多数 Sitara 工业平台适配项目，建议优先使用 TI 官方 SDK 工具链，因为它与 BSP 的 U-Boot、Kernel、设备树版本经过联合验证，能显著降低“编译通过但运行异常”的风险。若项目需要长期维护并计划迁移到其他 ARM 平台，可在 Yocto 中构建统一工具链，但必须自行验证内核模块的 vermagic 与目标内核一致。
modinfo 查看模块的 vermagic，或对比 uname -r 与编译时使用的内核头文件版本。工业现场升级内核后，务必重新编译所有内核模块。symbol not found 或段错误。完成工具链搭建与 hello world 验证后，后续的内核模块编译、应用程序移植、Qt 图形界面构建都将基于同一套环境变量和 sysroot。建议把 source environment-setup 固化到项目构建脚本中，并在 CI 中记录工具链版本号，确保团队内和长期构建的一致性。