4. 目标架构与工具链：选对CPU，配好刀

做嵌入式Linux，第一件事就是搞清楚：你的板子用的是什么CPU？

这听起来像废话，但我在项目里见过不止一次——有人拿着ARM的代码直接往MIPS上编译，结果跑起来全是段错误。嗯，这种坑踩一次就够了。

这一章，我们就来聊聊目标架构和工具链。说白了，就是给你的Buildroot选对“方言”和“翻译官”。

4.1 目标CPU架构：你的芯片是什么“血统”？

Buildroot支持的架构很多，但实际项目中，90%以上集中在下面几种：

4.2 工具链：内部 vs 外部，怎么选？

工具链就是编译器、链接器、库的集合。Buildroot给了你两条路：

• 内部工具链：Buildroot自己从源码编译gcc、binutils、glibc/uclibc/musl。
• 外部工具链：你提供一个预编译好的工具链，Buildroot直接用。

怎么选？我直接说结论：

为什么？

内部工具链的好处是“一键生成”，你不需要操心工具链从哪里来。但坏处也很明显——编译一次gcc要很久，我当年在奔腾4机器上等过整整一个下午。而且不同版本的Buildroot生成的工具链可能不兼容，团队里每个人编译出来的东西不一样，那就乱套了。

外部工具链呢？你从芯片厂商（比如ARM、NXP、TI）下载一个官方认证的工具链，或者用Linaro、Codesourcery的预编译版本。这样所有人都用同一把“刀”，编译出来的二进制完全一致。

4.3 配置内部工具链

在Buildroot的menuconfig里，路径是：

Target options  --->
  Target Architecture (ARM (little endian))  --->
  Target Architecture Variant (cortex-a7)  --->
  Target ABI (EABIhf)  --->
  Floating point strategy (NEON/VFPv4)  --->

Toolchain  --->
  Toolchain type (Buildroot toolchain)  --->
  C library (glibc / uclibc / musl)  --->
  Kernel headers (Same as kernel being built)  --->
  Custom kernel headers series (4.19.x)  --->
  Enable C++ support [*]
  Enable compiler optimizations [*]

这里有几个关键点：

• ABI：ARM有EABI和EABIhf。EABIhf用硬件浮点，性能好很多。如果你的芯片支持VFP，一定要选EABIhf。
• C library：glibc功能全但体积大；uclibc轻量但兼容性差；musl是后起之秀，安全性和性能都不错。我个人习惯：存储够用就glibc，空间紧张就musl。
• Kernel headers：最好和你的Linux内核版本匹配。不匹配的话，某些系统调用可能编译不过。

4.4 配置外部工具链

如果你决定用外部工具链，配置路径是：

Toolchain  --->
  Toolchain type (External toolchain)  --->
  Toolchain (Custom toolchain)  --->
  Toolchain path (/opt/arm-gcc-9.2)  --->
  Toolchain prefix (arm-linux-gnueabihf)  --->
  External toolchain C library (glibc / uclibc / musl)  --->
  External toolchain kernel headers series (4.19.x)  --->

这里要注意：

• Toolchain path：必须是绝对路径，而且工具链的bin目录下要有gcc、ld等可执行文件。
• Toolchain prefix：就是交叉编译器的前缀。比如你的编译器叫 arm-linux-gnueabihf-gcc，前缀就是 arm-linux-gnueabihf。
• Kernel headers：外部工具链自带了内核头文件，但版本可能和你的内核不匹配。Buildroot会检查，如果不匹配会报错。你可以选择“强制使用”或者自己重新打包工具链。

4.5 工具链验证：编译一个Hello World

配置好之后，别急着全量编译。先验证工具链能不能用。

在Buildroot的output目录下，找到 host/bin/ 或者你指定的外部工具链路径，然后：

$ arm-linux-gnueabihf-gcc -v
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabihf-gcc
...
gcc version 9.2.0 (GCC) 

$ cat hello.c
#include <stdio.h>
int main() {
    printf("Hello, Buildroot!\n");
    return 0;
}

$ arm-linux-gnueabihf-gcc -o hello hello.c
$ file hello
hello: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3

看到 ELF 32-bit LSB executable, ARM 就对了。如果显示的是 x86-64，说明你用的是本地编译器，不是交叉编译器——嗯，这个坑我也踩过。

4.6 知识体系图：目标架构与工具链决策流程

下面这张图，帮你理清整个决策过程：

4.7 常见问题与避坑

最后，分享几个我实际项目中遇到的坑：

• 工具链版本不匹配：用外部工具链时，gcc版本和Buildroot版本差距太大，会导致某些库编译失败。我建议gcc版本差距不要超过两个大版本。
• 浮点ABI冲突：选了EABIhf，但工具链不支持硬件浮点，编译出来的程序一运行就崩溃。检查工具链是否支持VFP/NEON，用 readelf -A 查看。
• 内核头文件不一致：Buildroot编译内核时用的头文件版本，和工具链自带的头文件版本不一致，会导致某些驱动编译报错。解决办法是手动指定内核头文件路径。
• 32位 vs 64位：ARM64的工具链不能编译ARM32的代码，反过来也不行。别搞混了。