Clang生成动态库需分平台指定参数：Linux用clang -fPIC -shared -o libfoo.so foo.c，macOS用clang -fPIC -dynamiclib -o libfoo.dylib foo.c，且-fPIC必须在编译阶段显式添加，否则链接失败。
Clang用-shared生成动态库的基本命令长什么样
直接用 clang -shared 无法生成可用的动态库，必须配合 -fPIC（位置无关代码）和明确的输出文件名。缺 -fPIC 会报错：relocation R_X86_64_32 against `.rodata' can not be used when making a shared object。
正确写法是：
clang -fPIC -shared -o libfoo.so foo.c
-
-fPIC必须加在编译阶段（哪怕只有一源文件），不是可选优化项，是 ABI 强制要求 -
-shared告诉链接器产出动态库，不是可执行文件 -
-o libfoo.so中的.so后缀是 Linux 惯例，Clang 不强制但系统加载器（如ld-linux）依赖它
多个源文件怎么一起编译成一个 .so
不能把所有 .c 文件一股脑塞给 clang -shared——得先各自编译为 .o，再链接。否则会触发重复定义或符号解析失败。
分两步更可控：
clang -fPIC -c a.c b.c -o a.o b.o<br>clang -shared -o libab.so a.o b.o
-
-c生成目标文件，不链接；-fPIC必须出现在这一步，不能只放在第二步 - 如果某源文件依赖外部头文件（比如
#include <math.h>），第二步要加-lm，但注意：库链接参数（-lm）必须放在-o之后、输入文件（a.o b.o）之后 - 避免用
clang -shared a.c b.c -o libab.so这种写法——Clang 会尝试隐式调用cc1多次，但行为不可靠，尤其含宏或条件编译时容易漏符号
为什么 macOS 上 clang -shared 不起作用
macOS 的 Clang 默认后端是 ld64，不认 -shared，它用 -dynamiclib 替代。硬用 -shared 会报错：unknown argument: '-shared'。
Clang 22.1.3
下载
Clang 22.1.3 Windows 64 位历史版本安装包，适合旧项目兼容、LLVM/Clang 工具链回退、编译行为对比、链接问题复现和 C/C++ 构建环境维护。
跨平台写法要区分：
# Linux<br>clang -fPIC -shared -o libfoo.so foo.c<br><br># macOS<br>clang -fPIC -dynamiclib -o libfoo.dylib foo.c
- macOS 动态库后缀是
.dylib，不是.so；运行时链接器（dyld）只识别该后缀（或.tbd） -
-fPIC在 macOS 上仍是必需的，但部分旧版本 Clang 可能默认开启，别依赖——显式写上最稳 - 如果项目需同时支持两端，建议用 CMake 或 Makefile 做平台判断，而不是手写条件命令
生成的 .so 怎么验证是否真的可加载
光看文件存在、file libfoo.so 显示 “shared object” 不够。真正要确认的是符号表完整、无未定义全局符号（除了系统库里的）。
两个快速检查命令：
nm -D libfoo.so | head -5 # 看导出的动态符号<br>ldd libfoo.so # 看依赖是否可解析（尤其注意 "not found" 行）
-
nm -D只显示动态导出符号（即其他模块dlopen后能拿到的），如果为空，说明没加__attribute__((visibility("default")))或默认隐藏了所有符号 -
ldd报not found不一定错——如果依赖的是libc.so.6这类系统库，通常没问题；但若出现自定义库名且路径不对，就得用-rpath或设置LD_LIBRARY_PATH - 用
readelf -d libfoo.so | grep PATH查看RPATH或RUNPATH是否包含预期路径，这是运行时找依赖的关键
实际写的时候最容易忽略的是：不同平台参数不互通、-fPIC 必须作用于编译而非链接、以及导出符号默认被隐藏。这些点不提前踩一遍，等 runtime 报 undefined symbol 就得倒查半天。
