lld链接时需用--soname=libfoo.so.1指定soname，不可用-soname；若通过clang调用须写-wl,--soname=libfoo.so.1；soname必须为纯文件名、不含路径，否则运行时加载失败。
lld 链接时怎么指定 SONAME
SONAME 是动态库加载时真正被记录在可执行文件 DT_SONAME 字段里的名字，运行时动态链接器（ld-linux.so）靠它找库。lld 不支持 -soname 这个 GNU ld 风格的选项，必须用 --soname（双横线）。
常见错误是写成 -soname=libfoo.so.1 或漏掉等号——lld 会静默忽略，生成的二进制里 DT_SONAME 为空，导致运行时报 cannot open shared object file。
-
lld -shared -o libfoo.so.1.2.0 --soname=libfoo.so.1 foo.o—— 正确：输出文件名任意，但DT_SONAME固定为libfoo.so.1 - 若用
clang驱动调用 lld，需加-Wl,--soname=libfoo.so.1，不能写-Wl,-soname=libfoo.so.1 - SONAME 中不应含路径，只保留文件名部分；否则运行时会去错目录找库，且违反 FHS 规范
lld 设置 RPATH 的两种方式及优先级差异
lld 支持 --rpath 和 --runpath，但二者行为不同：--runpath 写入 DT_RUNPATH，运行时搜索优先级高于 DT_RPATH；而 --rpath 写入 DT_RPATH，且在现代 glibc 中已被标记为 legacy（GNU ld 默认也倾向用 --runpath）。
典型陷阱是：设了 --rpath=/opt/lib 却发现程序仍去 /usr/lib 找库——可能因为系统设置了 LD_LIBRARY_PATH，或你链接时实际生效的是更早的 DT_RUNPATH（比如从某个依赖库继承而来）。
-
lld -o app main.o --rpath='$ORIGIN/../lib' --runpath='/opt/myapp/lib'→ 会同时写入两个字段，但运行时只用DT_RUNPATH路径 -
$ORIGIN在 lld 中完全支持，且是相对路径最安全的写法；不要硬编码绝对路径，否则移植即失效 - 若要彻底禁用 RPATH 类字段，加
--disable-new-dtags（此时--rpath写DT_RPATH，--runpath被忽略）
验证 SONAME 和 RPATH 是否生效
别依赖链接命令“看起来对”，必须用工具确认二进制里真实写入的内容。GNU readelf 和 objdump 都可，但注意 lld 输出的字段名和 GNU ld 略有差异。
- 查 SONAME：
readelf -d libfoo.so.1.2.0 | grep SONAME→ 应看到0x000000000000000e (SONAME) Library soname: [libfoo.so.1] - 查运行时库搜索路径：
readelf -d app | grep -E 'RPATH|RUNPATH'→ 若只看到RUNPATH，说明--runpath覆盖了--rpath - 检查是否用了
$ORIGIN解析：chrpath -l app（需安装 chrpath），它能直接显示解释后的路径逻辑
和 GNU ld 行为不一致的几个关键点
lld 更严格、更“直译”，不会自动补全或降级处理某些选项。实际集成时容易卡在这几处：
-
--rpath不接受逗号分隔多个路径，必须多次重复该选项：--rpath=/a --rpath=/b，而非--rpath=/a,/b - lld 默认不解析
.so后缀的版本别名（如libfoo.so→libfoo.so.1），这由ldconfig或SONAME控制，不是链接器责任 - 如果目标平台是 Android 或 HarmonyOS，
$ORIGIN可能不被其 loader 支持（例如旧版 Android bionic），此时必须用绝对路径或LD_PRELOAD临时绕过
最常被忽略的是：lld 的 --soname 和 --rpath 必须在链接共享库（-shared）或可执行文件（-pie）时显式传入，编译阶段（clang -c）加这些参数无效。
