运行时报“error while loading shared libraries”是因编译期链接成功但运行时动态链接器找不到库，根本原因是-l仅影响编译、-rpath才写入二进制供运行时使用，需按系统差异正确配置$origin/@loader_path/runpath。
编译能过但运行报 error while loading shared libraries
这是最典型的“链接成功、加载失败”现象。Clang（或底层链接器）在编译阶段已找到库符号并完成链接，但程序启动时，动态链接器（ld-linux.so / dyld）根本没去你放库的目录里找。
根本原因：-L 只影响编译期链接，对运行时完全无效。运行时搜索路径和编译时是两套独立机制。
- Linux 下用
ldd ./a.out查看依赖，若显示libxxx.so => not found，说明运行时路径缺失 - macOS 下用
otool -L ./a.out看是否列出了你的 dylib；若路径是绝对路径且不存在，或显示not found，就是加载失败 - 鸿蒙/Android NDK 环境下同理，需确认
readelf -d ./a.out | grep RUNPATH是否包含目标目录
用 -Wl,-rpath 把路径写进可执行文件
这才是让程序自己“记住去哪找库”的可靠方式。它把搜索路径硬编码进二进制的 RUNPATH 或 RPATH 段，运行时由系统动态链接器自动读取。
Clang 22.1.3
下载
Clang 22.1.3 Windows 64 位历史版本安装包，适合旧项目兼容、LLVM/Clang 工具链回退、编译行为对比、链接问题复现和 C/C++ 构建环境维护。
- Linux：直接用
clang++ main.cpp -L./lib -lmylib -Wl,-rpath,'$ORIGIN/../lib' -o main，注意单引号防止 shell 展开$ORIGIN - macOS：必须加
-Wl,-rpath,'@loader_path/../lib'（不是$ORIGIN），且要确保 dylib 的 install name 匹配，例如用install_name_tool -id "@rpath/libmylib.dylib" libmylib.dylib重设 - 鸿蒙/NDK：
$ORIGIN同样会被 shell 提前展开，得双层转义：-Wl,-rpath,\$$ORIGIN/../lib或改用绝对路径临时验证 - 验证是否生效：
readelf -d ./main | grep RUNPATH（Linux）、otool -l ./main | grep -A2 LC_RPATH（macOS）
LD_LIBRARY_PATH 是最快验证手段，但别用于部署
它只改当前 shell 进程的运行时库路径，适合调试和 CI 流水线临时绕过问题，不适合交付给用户。
- Linux/macOS 都支持：
LD_LIBRARY_PATH=./lib ./main - 鸿蒙 PC 当前也兼容该变量，但 musl libc 下行为略有差异，建议优先走
-rpath - 注意：它不解决多级依赖（比如你的库又依赖另一个未在该路径下的 so），此时仍会报错
- 如果用了
sudo，环境变量默认被清除，得加sudo env "LD_LIBRARY_PATH=$LD_LIBRARY_PATH" ./main
链接阶段就报 ld: library not found？检查 -L 和 -l 顺序
这个错误发生在编译链接期，说明 Clang 根本没找到库文件本身，不是运行时问题。
-
-L必须出现在对应-l之前，例如clang++ main.cpp -L./lib -lmylib -o main；写成-lmylib -L./lib会静默忽略 -L - 确认
./lib下确实有libmylib.so（Linux）、libmylib.dylib（macOS）或libmylib.z.so（带版本号时） - 如果库名不标准（如
mylib_static.a），不能用-lmylib_static，得写全路径：clang++ main.cpp ./lib/mylib_static.a - macOS 上若用 Homebrew 安装的 llvm，可能默认不找系统 SDK 路径，需补
--sysroot=$(xcrun --show-sdk-path)
真正容易被忽略的是：运行时路径和编译时路径彻底分离，且不同系统对 $ORIGIN、@loader_path、@rpath 的解析逻辑和默认启用状态完全不同。别假设一个命令在 Linux 成功，macOS 或鸿蒙就能照搬。
