结论：-wl,-rpath,/your/lib/path 是唯一可靠写法；g++ 不识别 -rpath，必须通过 -wl, 转发给链接器 ld，否则静默忽略导致运行时报“cannot open shared object file”。
g++ 编译时怎么用 -rpath 指定运行时 so 搜索路径
直接说结论：-Wl,-rpath,/your/lib/path 是唯一可靠写法。g++ 本身不识别 -rpath，它必须通过 -Wl, 转发给链接器 ld。漏掉 -Wl, 前缀会导致静默忽略，程序运行时仍报 libxxx.so: cannot open shared object file。
常见错误写法：g++ -rpath /usr/local/lib ... —— 这个 -rpath 被 g++ 当作无关参数丢弃，ld 根本没收到。
-
-Wl,-rpath,/usr/local/lib：单路径，最常用 -
-Wl,-rpath,'$ORIGIN/../lib'：用$ORIGIN实现相对路径（注意单引号防 shell 展开） -
-Wl,-rpath,/path/a -Wl,-rpath,/path/b：多个路径需重复写-Wl,-rpath, - 路径中不要加
lib/后缀或.so，只写目录
怎么验证 -rpath 是否生效
编译后立刻用 readelf -d your_executable | grep rpath 查看。输出里应有 0x000000000000001d (RUNPATH) 或 (RPATH) 条目，值为你指定的路径。别信 ldd your_executable 的输出——它只显示当前能解析到的库，不反映 rpath 设置是否被写入二进制。
如果看到 0x000000000000001d (RUNPATH)，说明用的是 GNU ld 2.26+ 默认的 RUNPATH（优先级高于 LD_LIBRARY_PATH）；若仍是 RPATH，说明链接器版本较老或显式用了 -Wl,--rpath（非 --enable-new-dtags 默认行为）。
-
readelf -d是唯一可信验证方式 -
objdump -p也能看，但输出格式不如readelf直观 - 运行时报错前，先确认
ls /your/rpath/libxxx.so真的存在且权限正常
-rpath 和 LD_LIBRARY_PATH 冲突时谁生效
-rpath（或 RUNPATH）优先级高于 LD_LIBRARY_PATH。但注意：如果二进制里写的是 RPATH（旧式），且设置了 LD_LIBRARY_PATH，后者会优先生效——这是历史兼容行为，容易踩坑。
- 现代构建建议统一用
-Wl,-rpath,...，并确认readelf输出是RUNPATH - 临时调试可设
LD_LIBRARY_PATH=/tmp/testlib:$LD_LIBRARY_PATH ./a.out，但不能替代-rpath -
LD_LIBRARY_PATH对 setuid 程序完全无效，-rpath是唯一选择
交叉编译或自定义工具链时 -rpath 容易出什么问题
交叉编译器（如 aarch64-linux-gnu-g++）的 -Wl,-rpath 语法不变，但路径必须指向目标机文件系统，不是宿主机路径。常见错误是把宿主机的 /usr/aarch64-linux-gnu/lib 写进 -rpath，导致目标机运行时去搜这个绝对路径，而实际库在 /lib 或 /usr/lib。
- 优先用
$ORIGIN：例如-Wl,-rpath,'$ORIGIN/../lib'，部署时保持目录结构即可 - 避免硬编码绝对路径，除非你完全控制目标机的 rootfs 结构
- 某些嵌入式 toolchain 的 ld 不支持
$ORIGIN，需查文档确认 - Android NDK 用户注意：
-rpath在 Android 上基本无效，得用android.bundle.library或 runtime 加载
真正麻烦的从来不是怎么写 -rpath，而是路径里的 $ORIGIN 被 shell 提前展开、交叉环境路径错位、或者误以为 ldd 能验证 rpath 是否写入成功。
