-rpath 是链接器参数，需用 -Wl,-rpath,/path 透传；它控制运行时库查找路径，与编译期的 -L/-l 解耦；macOS 支持 @loader_path 等动态占位符，但需避免硬编码绝对路径，且注意 strip 可能移除该信息。
clang -rpath 参数必须用 -Wl, 透传给链接器
直接写 -rpath /path/to/lib 是无效的，clang 会报错说不识别这个选项。因为 -rpath 实际是 ld（链接器）的参数，clang 本身只是前端，必须通过 -Wl, 告诉它“接下来的参数原样传给链接器”。
正确写法是：-Wl,-rpath,/path/to/lib（逗号分隔，不能有空格）。多个路径用多个 -Wl,-rpath,...，或合并为 -Wl,-rpath,/a:/b:/c（Linux/macOS 都支持冒号分隔）。
- macOS 上还常配合
-Wl,-rpath,@loader_path/../lib实现相对路径定位 - 如果路径含空格，得整个用引号包住：
-Wl,-rpath,"/path/with space" - 注意：
-rpath只影响运行时查找，不影响编译期头文件或静态链接
运行时生效的前提：可执行文件未被 strip 或 patch
-rpath 写入 ELF 或 Mach-O 的动态段（DT_RUNPATH 或 LC_RPATH），但某些工具（如 strip --strip-all、部分打包脚本、CI 中的二进制精简步骤）会删掉这些元数据，导致 -rpath 失效。
验证是否生效：
Clang 22.1.3
下载
Clang 22.1.3 Windows 64 位历史版本安装包，适合旧项目兼容、LLVM/Clang 工具链回退、编译行为对比、链接问题复现和 C/C++ 构建环境维护。
- Linux：用
readelf -d ./a.out | grep RUNPATH或objdump -x ./a.out | grep PATH - macOS：用
otool -l ./a.out | grep -A2 RPATH - 运行前检查：
LD_DEBUG=libs ./a.out 2>&1 | grep "search path"（Linux）
和 -L、-l 的关系容易混淆
-L 和 -l 只影响**编译链接阶段**——告诉链接器去哪找库、要链接哪个库名；而 -rpath 影响的是**程序运行阶段**——告诉 loader 去哪找同名的 .so/.dylib。两者完全解耦。
- 常见错误：只加
-L/path -lname，没加-Wl,-rpath,/path→ 编译成功，运行时报error while loading shared libraries: libxxx.so: cannot open shared object file - 更隐蔽的情况：开发机上有全局
/usr/local/lib，你本地-L指向自己编译的库，但漏了-rpath→ 程序在别人机器上跑，loader 去找系统默认路径，加载了旧版库，行为异常
macOS 的 @rpath 和 @loader_path 不是 clang 特性，是 dyld 规则
@rpath 是 macOS 动态链接器（dyld）的占位符，不是 clang 解析的。clang 只负责把字符串原样写进二进制；真正解释它的是运行时 dyld。
典型安全写法：
-
-Wl,-rpath,@loader_path/../lib：从可执行文件所在目录向上一级进lib目录找 -
-Wl,-rpath,@executable_path/../Frameworks：适用于 app bundle 结构 - 绝对路径慎用，尤其不要硬写
/Users/xxx/lib—— 这种路径在别人机器上必然失败
实际中，@loader_path 在绝大多数独立部署场景下比绝对路径更可靠，但要注意它解析的是“被加载者”的位置，不是主程序位置（比如插件 dlopen 加载时，@loader_path 指向插件自身路径）。
