链接时用-wl,-rpath指定运行时库路径，clang通过传递参数给链接器（如ld或lld）将路径写入二进制的dt_runpath或dt_rpath；必须配合$origin等路径使用并用readelf或objdump验证是否生效，否则运行时仍会报“cannot open shared object file”。
链接时用 -Wl,-rpath, 指定运行时库路径
Clang 本身不直接处理 rpath，而是通过传递参数给底层链接器（通常是 ld 或 lld）来设置。关键是在编译链接阶段用 -Wl,-rpath, 告诉链接器把路径写进二进制的 DT_RUNPATH 或 DT_RPATH 入口。
常见错误是只加 -L 而不加 -rpath，结果编译能过，运行时报 libxxx.so: cannot open shared object file: No such file or directory。
-
-Wl,-rpath,$ORIGIN/../lib：最常用，$ORIGIN表示可执行文件所在目录，相对路径更安全 -
-Wl,-rpath,/usr/local/lib：绝对路径，适合系统级部署，但会降低移植性 - 多个 rpath 用冒号分隔：
-Wl,-rpath,/path/a:/path/b - 避免混用
-rpath和-R（后者已被弃用，且行为可能不一致）
检查生成的二进制是否真写了 rpath
光加参数不一定生效——链接器可能忽略、覆盖或被其他标志干扰。必须用工具验证：
Clang 22.1.3
下载
Clang 22.1.3 Windows 64 位历史版本安装包，适合旧项目兼容、LLVM/Clang 工具链回退、编译行为对比、链接问题复现和 C/C++ 构建环境维护。
- 用
readelf -d your_executable | grep RUNPATH查看是否含DT_RUNPATH（现代默认） - 或
objdump -x your_executable | grep RPATH，注意区分RPATH（旧式，优先级高但不可被LD_LIBRARY_PATH覆盖）和RUNPATH（新式，可被覆盖） - 如果输出为空，说明
-rpath没生效，常见原因是：链接命令里-rpath写在了目标文件之后，或被构建系统（如 CMake）的默认策略覆盖
CMake 中正确设置 rpath 的写法
手动调 Clang 命令容易漏掉，CMake 更可靠但默认关闭 rpath。关键不是改 link_directories()，而是控制两个变量：
- 设
set(CMAKE_INSTALL_RPATH "$ORIGIN/../lib")，影响 install 后的产物 - 设
set(CMAKE_BUILD_RPATH "$ORIGIN/../lib")，影响 build 目录下的可执行文件 - 必须同时关掉自动清理：
set(CMAKE_SKIP_RPATH FALSE)（默认为TRUE，会删掉你设的 rpath） - 若用
find_library()找到的库没带 rpath，可在target_link_libraries()后补set_target_properties(your_target PROPERTIES INSTALL_RPATH "$ORIGIN/../lib")
$ORIGIN 在不同场景下的行为差异
$ORIGIN 看似简单，但实际解析依赖于程序启动方式，容易踩坑：
- 直接运行
./a.out：$ORIGIN 是当前工作目录下a.out的所在目录 - 用绝对路径运行
/home/user/bin/a.out：$ORIGIN 是/home/user/bin，不是pwd - 通过 symlink 启动：$ORIGIN 解析的是 symlink 指向的真实路径，不是 symlink 自身位置（除非用
$ORIGIN/.这种 trick） - 某些容器或沙盒环境（如 Flatpak）会重写 rpath 或屏蔽
$ORIGIN，此时需改用绝对路径或 runtime 预加载
rpath 不是“设了就完事”，它和文件布局、启动上下文强绑定，验证必须在目标环境中做，不能只信构建日志。
