clang编译程序默认无runpath，运行时因未固化库路径而报错；ld_library_path非首选因其易漏、难维护、有安全与冲突风险；正确写法须防shell提前展开$origin，如用单引号包裹'-wl,-rpath,$origin/lib'，并以readelf -d验证。
Clang 编译的程序默认不带 RUNPATH，运行时找不到动态库就直接报错：Error loading shared library libxxx.so: No such file or directory。这不是路径写错了，而是链接器没把查找路径“刻进二进制里”，得靠环境变量或编译时显式配置。
为什么 LD_LIBRARY_PATH 不是首选方案
临时设 LD_LIBRARY_PATH 确实能跑起来，但有硬伤：
- 每次运行都要手动 export，脚本里容易漏、CI/CD 里难维护
- 多个依赖库在不同子目录（比如
lib/和lib/plugins/）时，得拼一长串路径 - 容器或非 root 环境下可能被安全策略禁用（如
secure_getenv拒绝读取） - 和系统级库冲突风险高，比如你指定了
/opt/myapp/lib，结果它把libc.so也从那儿加载了
clang++ -Wl,-rpath 怎么写才生效
关键不是加参数，而是避免 shell 提前展开 $ORIGIN —— 这是绝大多数人卡住的地方。
错误写法：clang++ -Wl,-rpath,$ORIGIN/lib main.o -lmylib → shell 把 $ORIGIN 当成变量展开为空，实际传给链接器的是 -rpath,/lib，绝对路径失效。
正确写法（三选一）：
- 单引号包裹：
clang++ -Wl,-rpath,'$ORIGIN/lib' main.o -lmylib - 反斜杠转义：
clang++ -Wl,-rpath,$ORIGIN/lib main.o -lmylib - 环境变量双层转义（适合 Makefile 或 configure）：
LDFLAGS="-Wl,-rpath,\$ORIGIN/lib" ./configure
验证是否生效：readelf -d ./a.out | grep RUNPATH，输出应为 0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/lib]，注意括号里是 $ORIGIN 而不是展开后的路径。
Clang 22.1.3 Windows 64 位历史版本安装包，适合旧项目兼容、LLVM/Clang 工具链回退、编译行为对比、链接问题复现和 C/C++ 构建环境维护。
CMake 项目里怎么配 RUNPATH
CMake 默认不设 RUNPATH，哪怕你写了 link_directories() 也没用。必须显式设置属性：
- 对可执行目标：
set_property(TARGET myapp PROPERTY INSTALL_RPATH "$ORIGIN/lib") - 对所有目标统一设（推荐）：
set(CMAKE_INSTALL_RPATH "$ORIGIN/lib") - 如果依赖库在子目录（比如
lib/external/），写成：set(CMAKE_INSTALL_RPATH "$ORIGIN/lib:$ORIGIN/lib/external")
注意：INSTALL_RPATH 是构建时生效的值；若要调试阶段也生效，加一句：set(CMAKE_BUILD_RPATH "$ORIGIN/lib")。否则 build/ 目录下跑不起来。
鸿蒙 PC 或 musl 环境下的特殊处理
鸿蒙 PC（基于 musl）和部分嵌入式 Linux 发行版不支持 $ORIGIN 的递归解析，$ORIGIN/../lib 可能失败。这时别硬套相对路径，换更稳的方案：
- 用绝对路径（需部署时一致）：
-Wl,-rpath,/data/app/lib - 改用
-Wl,-rpath-link（仅编译期用，不影响运行时）+install_name（macOS 风格，musl 不支持）→ 不适用 - 最稳妥：交叉编译时用
--sysroot指向目标根文件系统，让链接器把路径“固化”为相对于 sysroot 的位置
另外，musl 的动态链接器不读 LD_LIBRARY_PATH（除非编译时加 --enable-env-ldpath），所以 RUNPATH 是唯一可靠路径。
真正麻烦的不是写哪条命令，而是确认二进制里到底有没有 RUNPATH、值对不对、路径层级是否匹配实际部署结构。每次改完都该用 readelf -d 看一眼，别信“应该没问题”。
