Yocto SDK下aarch64-poky-linux-gcc与${CC}交叉编译差异原因

核心差异在于Yocto SDK的环境配置脚本是通过shell环境变量封装了交叉编译所需的全部参数，直接调用编译器二进制和调用${CC}的本质区别是是否携带SDK预设的目标平台编译配置：

• 执行source /opt/fsl-imx-internal-xwayland/5.15-kirkstone/environment-setup-armv8a-poky-linux时，脚本会在当前shell会话导出一整套预置编译环境变量，包含CC/CXX/LD等工具链变量，以及CFLAGS/LDFLAGS/PKG_CONFIG_SYSROOT_DIR等编译链接参数。
• 执行echo $CC就能看到变量的实际内容，它并非单纯指向aarch64-poky-linux-gcc二进制，而是已经拼接了所有必填参数的完整调用命令，典型内容如下：

aarch64-poky-linux-gcc  -march=armv8-a+crc+crypto -mbranch-protection=standard -fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/opt/fsl-imx-internal-xwayland/5.15-kirkstone/sysroots/armv8a-poky-linux

• 使用${CC}编译时，上述参数会被完整传递给GCC，其中--sysroot参数指定了目标板的根文件系统路径，GCC会自动到该路径下搜索头文件、库文件，缺失的bits/libc-header-start.h就存放在目标sysroot的usr/include/bits目录下，自然不会报错；同时拼接的架构参数、优化选项、安全编译选项也都是匹配i.MX8硬件特性的配置。
• 直接调用裸的aarch64-poky-linux-gcc时，没有传入--sysroot参数，GCC不会自动关联对应目标架构的sysroot，只会搜索工具链自带的内置头文件目录，找不到目标架构glibc的平台相关头文件，就会触发你遇到的致命错误。就算手动补全sysroot参数，如果缺失-march=armv8-a+crc+crypto这类架构配置，编译出的程序也可能因为指令集不匹配无法在板端正常运行。

• 加载Yocto SDK环境后，不要直接调用aarch64-poky-linux-gcc这类裸工具链二进制，优先使用${CC}/${CXX}等预置变量编译，或在手动调用时追加$CFLAGS/$LDFLAGS变量中的参数。
• 使用Makefile、CMake等构建系统时，不要手动硬编码编译器路径，构建系统会自动读取当前shell环境中的CC/CXX等变量配置，避免参数缺失。
• 若必须直接调用编译器二进制，必须手动指定--sysroot参数指向对应目标的sysroot路径，同时补充匹配目标硬件的架构编译选项。

补充说明：Yocto SDK采用环境变量封装的设计，是为了实现同一份工具链兼容多个目标配置——切换不同的environment-setup脚本，就能支持不同架构、不同CPU特性、不同系统配置的目标平台，不需要为每个目标单独编译一套GCC二进制。

内容的提问来源于stack exchange，提问作者Chong Chong