clang -shared 生成动态库必须配合 -fPIC，否则链接失败；C++ 动态库需加 -fvisibility=hidden 防符号污染；.o 文件合并时须全为 PIC；运行时路径需通过 -rpath 或 LD_LIBRARY_PATH 指定。
clang -shared 生成动态库的基本用法
直接加 -shared 就能生成动态库，但必须配合 -fPIC（位置无关代码），否则链接会失败。clang 默认不开启 PIC，这点和 gcc 一致，但错误提示不如 gcc 明确，容易卡在 undefined reference 或 relocation R_X86_64_32 错误上。
-
clang -fPIC -shared -o libfoo.so foo.c是最简可行命令 - 源文件里不能有
main函数，动态库不需要入口点 - 如果引用了其他动态库（如
libm），需用-lm，但注意：链接时加，不是编译时加 ——-shared阶段只负责把目标文件打包，真正解析外部符号靠运行时或加载时
为什么 clang 编译 C++ 动态库要额外加 -fvisibility=hidden
C++ 的符号默认全局可见，容易造成符号冲突或意外导出（比如模板实例、内联函数、匿名命名空间里的东西）。不控制 visibility，nm -D libxxx.so 会看到一堆不该暴露的符号，影响 ABI 稳定性和加载速度。
Clang 22.1.3
下载
Clang 22.1.3 Windows 64 位历史版本安装包，适合旧项目兼容、LLVM/Clang 工具链回退、编译行为对比、链接问题复现和 C/C++ 构建环境维护。
- 推荐加
-fvisibility=hidden，再对需要导出的函数/类显式标记__attribute__((visibility("default"))) - 头文件里可以封装宏：
#define EXPORT __attribute__((visibility("default")))，然后EXPORT void init(); - 漏加
-fvisibility=hidden不报错，但后续被其他项目 dlopen 时可能因符号污染崩溃，尤其在多插件场景下
clang -shared 链接已有 .o 文件 vs 直接编译 .c
两种方式都行，但行为有差异：直接编译 .c 会隐式调用汇编和链接；用已编译的 .o 则跳过前端，更可控，也方便做增量构建。
- 从 .o 合并：
clang -shared -o libbar.so bar.o helper.o -L/path/to -lqux - 注意：所有 .o 必须都是
-fPIC编译出来的，哪怕其中一个不是，-shared也会失败（clang 报错：relocation R_X86_64_PC32） - 可以用
readelf -h bar.o | grep Type确认是否为 REL（可重定位），而不是 EXEC（可执行）
运行时报 “cannot open shared object file” 怎么快速定位
这不是 clang 编译问题，而是运行时链接器找不到库路径。clang 本身不干预运行时搜索逻辑，-rpath 或环境变量才是关键。
- 编译时嵌入路径：
clang -shared -Wl,-rpath,/usr/local/lib -o libfoo.so foo.c（-Wl把参数透传给 linker） - 临时测试可用
LD_LIBRARY_PATH=/path/to/libs ./a.out，但别在生产环境依赖它 - 检查是否真的生成了 soname：
readelf -d libfoo.so | grep SONAME；没设的话默认是空，系统按文件名找，设了就按 soname 找 —— 这个细节常被忽略，导致升级后旧程序仍加载老库
