典型现象是程序在目标板上段错误，readelf显示依赖libc.so.6等通用名库，file显示为x86_64，ldd在宿主机通但在目标板not found；根本原因是链接未走交叉sysroot而回退至宿主机/usr/lib。
链接时误用宿主机库的典型现象
程序在目标板上直接段错误，readelf -d 显示依赖了 libc.so.6 或 libstdc++.so.6 这类通用名动态库；file ./a.out 报告是 x86_64 可执行文件，但你明明指定了 -target aarch64-linux-gnu；ldd ./a.out 在宿主机上能跑通，但在目标板上提示 not found ——这说明链接器根本没走交叉工具链的 sysroot，而是 fallback 到了宿主机的 /usr/lib。
检查 clang 是否真正启用交叉链接路径
Clang 默认不会自动切换链接器行为，必须显式传参。只加 -target 不够，它只控制前端代码生成，后端链接仍可能走系统默认 ld。
- 必须加
--sysroot=/path/to/sysroot，且该路径下需有usr/lib和usr/include - 显式指定链接器：加
-fuse-ld=lld（推荐）或-fuse-ld=/path/to/aarch64-linux-gnu-ld - 禁用宿主机库搜索：
-nostdlib+ 手动链接 crt1.o、crti.o、libc.a 等（嵌入式常用），或至少加-nodefaultlibs - 验证命令是否生效：在编译命令末尾加
-###，它会打印出 clang 实际调用的链接命令，重点看ld.lld或ld后面跟的-L路径和--sysroot
sysroot 不完整导致悄悄回退到宿主机库
即使指定了 --sysroot，如果里面缺 lib/libc.a 或 lib/crt1.o，clang 会在警告后自动 fallback 到 /usr/lib，而这个过程往往不报错，只输出一行 note: linking with the native linker 类似提示，极易被忽略。
- 用
ls -R /path/to/sysroot | grep -E "(crt|libc\.a|libm\.a)"确认基础启动文件和静态库存在 - 若用 Buildroot 或 crosstool-ng 生成的工具链，sysroot 通常在
output/staging/下；若手动构建，需确保make install DESTDIR=xxx时已安装 libc - 临时测试：把
--sysroot指向一个空目录，看是否立刻报cannot find crt1.o—— 如果不报，说明 clang 根本没认真用它
lld 链接器未启用 target-specific backend
LLVM 的 lld 默认按宿主机架构工作。即使你用 aarch64-linux-gnu-clang，若没告诉 lld 目标格式，它仍可能输出 ELF64-x86-64。
- 必须加
--target=aarch64-linux-gnu给 lld（注意：这是传给链接器的参数，不是 clang 的-target） - 正确写法示例：
clang --target=aarch64-linux-gnu --sysroot=/opt/sysroot -fuse-ld=lld -Wl,--target=aarch64-linux-gnu hello.c - 验证输出：
readelf -h ./a.out | grep -E "(Class|Data|Machine)"应显示ELF64、LSB、AARCH64
最容易被忽略的是 -Wl,--target=... 这个参数——它不写，lld 就不知道自己该生成什么架构的二进制，而 clang 也不会替你兜底。
