Clang生成动态库报错绝大多数非语法问题，而是链接阶段或ABI兼容性层面的隐性配置偏差，如缺失-fPIC、符号未导出、$ORIGIN被shell提前展开等。
Clang 生成动态库时报错，绝大多数情况不是语法问题，而是链接阶段或 ABI 兼容性层面的“隐性断点”——比如 undefined symbol、cannot find -lxxx、relocation R_X86_64_32 against symbol 这类错误，背后往往藏着 -fPIC 缺失、符号未导出、或 $ORIGIN 被 shell 提前展开等实际可修复的配置偏差。
clang -shared 编译失败：missing -fPIC 是头号原因
Linux/macOS 下用 clang 生成 .so 或 .dylib 时，如果源文件没加 -fPIC，链接器会直接报 relocation 错误。这不是警告，是硬性拒绝。
-
-fPIC必须在编译目标文件阶段就启用，不能只加在-shared那一步 - 正确流程是：
clang -fPIC -c func.c -o func.o→clang -shared func.o -o libfunc.so - 如果直接写
clang -shared func.c -o libfunc.so，clang 内部会尝试隐式加-fPIC，但某些版本（尤其旧版或交叉编译链）不保证生效 - macOS 上还需额外加
-dynamiclib替代-shared，否则生成的是普通可执行格式
运行时报 undefined symbol：符号根本没进动态库
编译通过、链接成功，但运行时提示 undefined symbol: Java_com_example_Foo_bar 或类似 C 函数名，说明符号压根没被导出到动态库中。
Clang 22.1.3
下载
Clang 22.1.3 Windows 64 位历史版本安装包，适合旧项目兼容、LLVM/Clang 工具链回退、编译行为对比、链接问题复现和 C/C++ 构建环境维护。
- 检查源文件里对应函数是否用了
JNIEXPORT修饰（JNI 场景）；C 函数则要确认没被static限定 - 用
nm -D libfunc.so查看动态导出符号表，确认目标符号出现在列表里（带T或D标记） - Clang 默认不导出所有符号，如需强制导出全部（不推荐），可加
-Wl,-export-dynamic - C++ 函数要注意 name mangling：用
c++filt解码报错里的乱码符号名，再核对头文件声明与实现是否一致
ldd -r 报告 undefined symbol：依赖库没被正确链接
主程序能编译，但 ldd -r ./main 显示一堆 “undefined symbol”，说明你链接了动态库，但它自己又依赖别的库，而那些库没参与链接过程。
- 不要只写
clang main.c libfunc.so -o main—— 这只把libfunc.so当作输入对象，不解析其内部依赖 - 正确做法是显式链接它所依赖的库，例如：
clang main.c -L. -lfunc -lcurl -lssl -o main - 或者用
-Wl,--no-as-needed防止链接器丢弃未显式引用的依赖库 - 若依赖库路径不在系统默认路径（如
/usr/lib），必须同时加-L/path/to/libs和对应-lxxx
鸿蒙/Android/交叉编译环境里 $ORIGIN 失效
在非标准 Linux 环境（如鸿蒙 PC、NDK）中设置 -Wl,-rpath,$ORIGIN/../lib 后，readelf -d 显示 RUNPATH 变成 ../lib，说明 $ORIGIN 被 shell 提前展开了。
- 根本原因是
$在 shell 中触发变量替换，而ORIGIN不是环境变量，结果为空 - 解决方法：对
$转义，写成-Wl,-rpath,\$ORIGIN/../lib（注意反斜杠） - 使用 CMake 时，应设
set(CMAKE_INSTALL_RPATH "$ORIGIN/../lib")，CMake 会自动处理转义 - 验证是否生效：
readelf -d your_binary | grep RUNPATH，输出必须含$ORIGIN字样，不能是空路径
真正卡住人的从来不是“怎么写命令”，而是 clang 在不同平台、不同构建系统下对 -fPIC、符号可见性、$ORIGIN 展开时机这些细节的差异化处理——漏掉任何一个，都会让错误藏在看似正常的编译日志后面。
