直接结论：不是编译器出错，而是-target三元组写错或未配--sysroot导致clang用错头文件和链接器；正确写法如aarch64-unknown-linux-gnu，且--sysroot必须指向含usr/include和usr/lib的目标根文件系统。
直接结论：不是编译器出错，是 -target 三元组写错了，或没配 --sysroot 导致 clang 用错了头文件和链接器。
clang -target 写错是最常见原因
LLVM 不靠工具链前缀（如 arm-linux-gnueabihf-gcc）区分架构，全靠 -target 参数。写错就直接进错 ABI 路径，连 stdio.h 都找不到。
-
armv7-linux-gnueabihf❌ —— clang 不识别，报error: unable to create target -
arm-linux-gnueabihf❌ —— 不是标准三元组，clang 可能静默降级为 generic x86 目标 -
armv7a-unknown-linux-gnueabihf✅ —— 32 位 ARM Linux 的标准 target -
aarch64-unknown-linux-gnu✅ —— 64 位 ARM Linux 的标准 target
CPU 名也别太具体：-mcpu=cortex-a9 容易触发 unknown target CPU 错误；换成 -mcpu=generic 更稳。
不配 --sysroot 就等于没交叉编译
clang 默认只用自带的 minimal headers（clang --print-resource-dir 查路径），根本不是目标平台的 usr/include。没 --sysroot，它会偷偷用宿主机的 /usr/include，导致结构体大小、宏定义、size_t 类型全错。
-
--sysroot必须指向一个真实的目标平台根文件系统目录，里面要有usr/include和usr/lib - 不能用
debootstrap给 amd64 构建的 sysroot，必须指定--arch=armhf或--arch=arm64 - 动态链接时，
--sysroot下还得有lib/ld-linux-armhf.so.3或lib/ld-linux-aarch64.so.1 - 静态链接（
-static）也不能省--sysroot，否则cannot find -lc
CMake 中漏传 target 和 sysroot 是高频坑
CMake 默认只设 CMAKE_C_COMPILER，但 LLVM 不像 GCC 那样自动推导 -target 和 sysroot。光写 set(CMAKE_C_COMPILER clang)，实际调用时还是本地 x86 编译。
- 必须在 toolchain 文件里把
--target和--sysroot塞进CMAKE_C_FLAGS，不能只靠环境变量 - 链接阶段同样要传
--target，否则clang++调用的ld可能是宿主机的ld.gold，拒绝链接 ARM 目标文件 - 验证是否生效：加
-v参数看 clang 实际执行命令，确认--target=...和--sysroot=...出现在每条命令里
链接时报 “file not recognized: file format not recognized” 怎么办
这是典型的架构错配结果：编译出了 ARM 目标文件，但链接器被 clang 调成了 x86 版本，或者用了错误的 sysroot 下的 ld。
- 先用
file hello.o确认目标文件确实是 ARM：ELF 32-bit LSB relocatable, ARM, EABI5或ELF 64-bit LSB shared object, ARM aarch64 - 再看
clang -v ...输出末尾调用的链接器路径，确保它来自你指定的--sysroot或 LLVM 自带的lld（推荐用-fuse-ld=lld避免 GNU ld 兼容问题） - 如果用的是 GNU binutils 工具链，确保
aarch64-linux-gnu-ld或arm-linux-gnueabihf-ld在PATH里，且 clang 没被误导去调用/usr/bin/ld
最硬核的验证方式：跳过 clang，直接拿生成的 .o 文件用目标平台的 ld 手动链接——能过，说明 clang 的参数没传到位；不过，说明 sysroot 或工具链本身有问题。
