ld.lld报undefined symbol一定发生在静态链接阶段，与运行时机制无关；需用nm和readelf分别确认调用方（.o）是否含u引用、提供方（.a/.so）是否导出该符号，并核查架构匹配、构建文件完整性、符号可见性及api level版本一致性。
ld.lld报undefined symbol时，先确认是链接阶段还是运行时
LLVM的ld.lld是链接器，不是动态加载器——它报的undefined symbol一定发生在**静态链接阶段**（即生成可执行文件或共享库时），和LD_LIBRARY_PATH、ldconfig这些运行时机制完全无关。这点常被混淆：看到“undefined symbol”就去查ldd -r，结果徒劳无功。
典型现象是：clang++编译通过，但链接时报错类似：
ld.lld: error: undefined symbol: android::RefBase::decStrong(void const*) const >>> referenced by StrongPointer.h:182 >>> out/target/product/hello/obj/EXECUTABLES/hello_intermediates/hello.o:(say_hello(char const*, char*, int))
这说明hello.o里调用了该符号，但链接器在所有输入的.o和.a中都没找到它的定义。
用nm和readelf快速定位符号在哪缺失
核心思路：分别检查「谁在用」和「谁该提供」。
- 查调用方（.o文件）是否真有未定义引用：
nm -C hello.o | grep decStrong→ 若输出含U android::RefBase::decStrong，确认是它发起的调用 - 查提供方（比如
libutils.a）是否真导出了该符号：nm -C libutils.a | grep decStrong→ 若无输出，说明该静态库没包含这个函数的实现 - 若怀疑是C++ ABI或模板实例化问题，加
-D参数看动态符号表：readelf -d libutils.so | grep NEEDED确认依赖是否完整，再用nm -D libutils.so | grep decStrong
注意：nm -C自动demangle C++符号名；不加-C看到的是_mangled形式（如_ZN7android7RefBase10decStrongEPKv），难读且易误判。
常见缺失原因及对应修复动作
不是所有“找不到”都源于漏编译。LLVM LLD比GNU ld更严格，以下情况极易触发报错：
-
static函数或未实例化的模板被头文件内联调用，但定义所在源文件未加入构建 → 检查Android.mk或CMakeLists.txt是否漏掉了RefBase.cpp等关键源码 - 目标平台配置错误：比如为
arm64编译了libutils.a，但链接时却混入了x86_64的hello.o→ 用file hello.o和file libutils.a核对架构是否一致 - 符号被
visibility=hidden或__attribute__((visibility("hidden")))屏蔽 → 查RefBase.h是否带#pragma GCC visibility push(hidden)且未在实现处显式导出 - 链接顺序颠倒：若
libutils.a依赖libcutils.a，而链接命令把libcutils.a放在前面 → LLD要求依赖者必须在被依赖者之后，即ld.lld hello.o libutils.a libcutils.a
避免重复踩坑的关键细节
LLD默认启用--no-undefined（GNU ld需手动加），所以哪怕一个符号漏掉，整个链接就失败。它不给你“先连上、运行时报错”的宽容机会。
最容易被忽略的是：某些Android系统库（如libutils）在不同API Level下符号签名会变。例如decStrong在Android R后改为带const修饰，而旧版头文件可能没同步更新。此时光看#include <utils></utils>没用，得确认你用的libutils.a版本和头文件版本严格匹配——这往往藏在out/target/product/xxx/obj/STATIC_LIBRARIES/路径里，而不是系统/usr/lib下。
