-l和-L必须配对使用：-L指定库路径，-l指定库名（去掉lib前缀和.so/.dylib后缀），且-L必须在-l之前；链接成功不等于运行成功，需通过rpath或环境变量解决运行时库查找问题。
链接动态库时 -l 和 -L 参数必须配对使用
Clang 本身不负责查找库文件，它只按你给的指令去链接。如果你只写 -lmylib，Clang 会默认在系统标准路径（如 /usr/lib）里找 libmylib.so；找不到就报错 ld: library not found for -lmylib。实际项目中动态库往往在自定义路径下，必须用 -L/path/to/libs 显式告诉链接器去哪里找。
常见错误现象：
- 编译通过但运行时报
dyld: Library not loaded（macOS）或error while loading shared libraries（Linux）——说明链接阶段找到了，但运行时没找到 - Clang 报
undefined reference to 'xxx'——不是没链接上，而是头文件声明了但链接器根本没看到符号定义，大概率是-l写错名或-L路径不对
正确写法示例（假设 libjson.so 在 ./deps/lib 下）：
clang main.c -L./deps/lib -ljson -o app
注意：-L 必须写在 -l 前面，顺序很重要；-ljson 中的 json 是库名，不是文件名，Clang 会自动补前缀 lib 和后缀 .so（或 .dylib）。
运行时找不到动态库：LD_LIBRARY_PATH 和 rpath 是关键
链接成功 ≠ 运行成功。Linux 下靠 LD_LIBRARY_PATH 或二进制中嵌入的 rpath 告诉 loader 去哪加载；macOS 用 DYLD_LIBRARY_PATH 或 -rpath（注意不是 LD_* 系列）。
推荐优先用 -rpath，避免依赖环境变量：
- Linux：
clang main.c -L./lib -lfoo -Wl,-rpath,'$ORIGIN/lib' -o app - macOS：
clang main.c -L./lib -lfoo -Wl,-rpath,@loader_path/lib -o app
$ORIGIN（Linux）和 @loader_path（macOS）都表示可执行文件所在目录，这样把 ./lib 和 app 放一起就能直接运行，不用改环境变量。
验证是否生效：
- Linux：用
readelf -d app | grep RPATH - macOS：用
otool -l app | grep -A2 RPATH
macOS 上 dylib 名称和兼容性版本容易踩坑
macOS 对动态库名称更敏感。Clang 链接时用 -lfoo，但实际要求 libfoo.dylib 的 install name（即内部标识名）也得匹配，否则运行时报 Library not loaded: libfoo.dylib，哪怕文件就在旁边。
Clang 22.1.3 Windows 64 位历史版本安装包，适合旧项目兼容、LLVM/Clang 工具链回退、编译行为对比、链接问题复现和 C/C++ 构建环境维护。
检查当前 dylib 的 install name：
otool -D libfoo.dylib
如果输出不是 libfoo.dylib 或你想用的路径，得用 install_name_tool 改：
install_name_tool -id "libfoo.dylib" libfoo.dylib
或者链接时直接指定：
clang -shared -o libfoo.dylib foo.o -install_name libfoo.dylib
另外，macOS 默认启用 hardened runtime，若 dylib 没签名或路径含 ~、../ 等，可能被系统拦截——开发阶段可临时加 -Wl,-no_adhoc_codesign 绕过，但上线必须签名。
静态库和动态库混用时，-l 顺序决定符号解析结果
如果同时链接 liba.so 和 libb.a，且 liba.so 依赖 libb.a 里的符号，那么 -la -lb 可能失败，因为链接器从左到右扫描，处理完 -la 时还不知道 libb.a 提供什么符号。
解决方法只有两个：
- 把依赖方放后面：
-lb -la（即“被依赖的库在前”） - 用
--no-as-needed（Linux）或重复-l（如-la -lb -la）强制重扫
更稳妥的做法是避免混用，或者用 -Wl,--whole-archive -lb -Wl,--no-whole-archive 把静态库所有符号无条件拉进来。
真正麻烦的是跨平台项目：Linux 的 .so、macOS 的 .dylib、Windows 的 .dll，不仅后缀不同，rpath 机制、命名规则、甚至链接时是否需要导入库（.lib）都不同——别指望一个 Makefile 全平台通用。
