Clang交叉编译共享库必须显式指定--sysroot，否则默认使用宿主机路径导致头文件类型错位、符号缺失或运行崩溃；--sysroot需完整包含usr/include、usr/lib及对应动态链接器，且第三方库路径须配合-rpath-link和-L显式指定。
clang交叉编译共享库必须显式传--sysroot，否则头文件和符号全错
不设 --sysroot 就编译 ARM 共享库，clang 会默认用宿主机（x86_64）的 /usr/include 和 /lib，结果是：编译能过，但 stdio.h 类型定义错位、struct stat 偏移不对、dlfcn.h 缺失，最终 dlopen 运行时崩溃或 undefined reference to 'memcpy' 链接失败。
关键点在于：clang 不像 gcc 那样隐式绑定工具链自带 sysroot；它只靠 --target 决定指令生成，所有路径都得你手动喂。
-
--sysroot路径下必须包含完整的usr/include（含bits/、asm/、linux/）、usr/lib（含libdl.so、libm.so）和lib/ld-linux-armhf.so.3（对 ARM32）或lib/ld-linux-aarch64.so.1（对 ARM64） - 不能用
debootstrap --arch=armhf后直接删掉/bin或/sbin——这些目录缺失不影响编译，但usr/lib下若缺libc_nonshared.a，静态链接-shared会报cannot find -lc - 若共享库依赖 OpenSSL 或 zlib，它们的头文件（如
openssl/ssl.h）必须放在$SYSROOT/usr/include下，不能只放$SYSROOT/include——clang不自动查include子目录
编译 .so 时要加 -fPIC 和 --sysroot 一起用，顺序不能反
clang 对 -fPIC 和 --sysroot 的解析有依赖顺序：如果 --sysroot 放在 -fPIC 后面，某些旧版（
正确写法示例（ARM32）：
clang -target armv7a-unknown-linux-gnueabihf \ --sysroot=/opt/sysroots/armhf \ -fPIC -shared -o libfoo.so foo.c
常见错误现象：error: unknown type name 'size_t' ——本质是 stddef.h 没从 /opt/sysroots/armhf/usr/include 加载，而是加载了 x86_64 的版本。
- 务必把
--sysroot放在所有-I、-L、-fPIC之前 - 如果用了
-I/opt/sysroots/armhf/usr/include，必须同时配--sysroot=/opt/sysroots/armhf，否则#include <sys/socket.h>仍可能失败（因为该头文件依赖bits/下的架构特定宏） - 链接阶段若报
cannot find -ldl，检查$SYSROOT/usr/lib/libdl.so是否存在；若只有libdl.so.2，需建软链接或加-Wl,-soname,libdl.so.2
第三方库 configure 脚本里怎么安全传 --sysroot
直接跑 ./configure --host=arm-linux-gnueabihf --sysroot=/path 大概率失败——绝大多数 autoconf 生成的脚本根本不认识 --sysroot 参数，它会被忽略，然后 configure 用宿主机的 gcc 测头文件，测出一堆 “not found”。
真正生效的方式是通过环境变量透传：
CC="clang --sysroot=/opt/sysroots/armhf -target armv7a-unknown-linux-gnueabihf" \ CFLAGS="--sysroot=/opt/sysroots/armhf -fPIC" \ LDFLAGS="--sysroot=/opt/sysroots/armhf -L/opt/sysroots/armhf/usr/lib" \ ./configure --host=arm-linux-gnueabihf
注意点：
-
CFLAGS里的--sysroot仅影响预处理和编译，LDFLAGS里的才控制链接器搜索路径；漏掉任一者都会断在不同阶段 - 很多库（如 curl、sqlite3）的 configure 会调用
pkg-config，必须提前设PKG_CONFIG_SYSROOT_DIR=/opt/sysroots/armhf，否则它仍去查宿主机的.pc文件 - 若 configure 报
checking for library containing socket... no，大概率是--sysroot没进到链接命令里，用./configure ... --verbose 2>&1 | grep ld看实际链接命令是否带--sysroot
链接时动态库路径没写进 ELF？得靠 -rpath-link 配合 --sysroot
编译出的 .so 若依赖其他第三方 .so（比如 libz.so），只设 --sysroot 不够：链接器在构建阶段找不到依赖，会报 undefined reference to 'deflate'，即使 libz.so 明明在 $SYSROOT/usr/lib 下。
原因：--sysroot 控制的是“头文件 + 默认系统库”路径，而第三方库路径需要额外告诉链接器。
- 加
-Wl,-rpath-link,/opt/sysroots/armhf/usr/lib让链接器在构建时能找到libz.so - 如果
libz.so在$SYSROOT/usr/lib/aarch64-linux-gnu/下（常见于 Debian/Ubuntu sysroot），必须显式加-L/opt/sysroots/armhf/usr/lib/aarch64-linux-gnu，--sysroot不自动展开这个子目录 - 运行时想让程序找到
libfoo.so，得在最终可执行文件链接时加-Wl,-rpath,'$ORIGIN/../lib'，但这和--sysroot无关，属于部署阶段问题
最易被忽略的是：交叉编译环境下，-rpath-link 必须和 --sysroot 指向同一棵树，否则链接器会混淆宿主机与目标机的库 ABI。
