结论：$origin消失是因shell提前展开为空，必须双引号加转义写成'\$origin/../lib'；-fpic须在编译.o阶段启用；运行时路径依赖正确注入runpath而非-l或ld_library_path。
直接结论：用 -Wl,-rpath= 编译时写死路径最可靠，但必须对 $ORIGIN 做 shell 转义，否则会被提前展开为空字符串。
Clang编译时加 -rpath 为什么 $ORIGIN 消失了
这是最常见的坑：你写 clang -Wl,-rpath=$ORIGIN/../lib ...，结果运行时动态链接器根本找不到库。原因不是 clang 不支持 $ORIGIN，而是 shell 在执行命令前就把 $ORIGIN 当成环境变量去展开——而它不存在，所以变成空，最终传给链接器的是 -rpath=../lib，相对路径失效。
- 验证方法：用
readelf -d your_binary | grep rpath看实际写入的 RUNPATH 值 - 正确写法必须双引号包裹并转义美元符：
clang -Wl,-rpath='$ORIGIN/../lib' ... - 如果通过
LDFLAGS传递（比如 autotools），需用单引号套住整个值：export LDFLAGS="-Wl,-rpath='$ORIGIN/../lib'"
Clang生成动态库时要不要加 -fPIC
要，而且必须在编译目标文件阶段就加，不能只在链接时加。
Clang 22.1.3
下载
Clang 22.1.3 Windows 64 位历史版本安装包，适合旧项目兼容、LLVM/Clang 工具链回退、编译行为对比、链接问题复现和 C/C++ 构建环境维护。
-
-fPIC是生成位置无关代码的开关，影响的是.o文件本身结构；没它，后续链接成.so会失败或运行时报错 - 典型错误：
relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `xxx' can not be used when making a shared object - 正确流程：
clang -fPIC -c foo.c -o foo.o→clang -shared foo.o -o libfoo.so - 如果源码多文件，每个
.c都得单独加-fPIC编译，不能跳过
Clang链接可执行文件时怎么指定动态库路径
分两步：编译期告诉链接器去哪里找 .so，运行期告诉 loader 去哪里加载它们。
- 编译期找库（决定是否能连上）：
-L/path/to/libs -lfoo，其中-L加的是目录，-lfoo会去找libfoo.so - 运行期加载路径（决定能否运行）：
-Wl,-rpath=/path/to/libs或-Wl,-rpath='$ORIGIN/../lib' - 注意：
-L不影响运行时行为，LD_LIBRARY_PATH优先级高于RUNPATH，但不推荐依赖它做部署 - 验证运行时路径是否生效：
ldd your_executable输出里看libfoo.so => not found还是显示具体路径
鸿蒙PC或Android交叉编译时 $ORIGIN 的实际取值
$ORIGIN 展开为**可执行文件自身所在的目录**，不是当前工作目录，也不是构建目录。
- 例如：你把
curl放到/usr/bin/curl，那$ORIGIN/../lib就是/usr/lib - 鸿蒙PC 上若把二进制和
.so都装到/system/bin/和/system/lib/，用'$ORIGIN/../lib'就刚好匹配 - Android NDK 中常用
'$ORIGIN/./'或'$ORIGIN/../lib'，取决于lib/目录相对于 so 文件的位置 - 别用
./或绝对路径硬编码——前者依赖 cwd，后者破坏可移植性
真正麻烦的不是写对命令，而是确认 readelf -d 输出的 RUNPATH 字符串里，$ORIGIN 是否还完整存在；只要它被 shell 吃掉一次，整个路径就废了。
