--as-needed 控制DT_NEEDED是否写入动态段，仅影响运行时自动加载的库列表而非链接成功与否；它按命令行顺序作用于后续库，需显式指定以避免ARM/Linux等平台默认差异引发的依赖问题。
LLD 的 --as-needed 控制 DT_NEEDED 是否写入动态段
它不改变链接是否成功，只决定生成的可执行文件或共享库的 DT_NEEDED 条目里有没有某条依赖记录。这个标记直接影响运行时 ld-linux.so 加载哪些库——没进 DT_NEEDED，就不会被自动加载，哪怕链接时用到了其中的符号。
常见错误现象：
- 链接通过，但运行时报
undefined symbol: xxx，而该符号明明在某个.so里 -
readelf -d ./a.out | grep NEEDED发现缺了本该有的库名 - 手动加
LD_PRELOAD=libxxx.so ./a.out就能跑通
使用场景：
- 构建精简嵌入式镜像时，避免带入未实际调用的依赖库
- 解决多个同名符号（如不同版本的
libcrypto.so）冲突问题 - 配合
--no-as-needed强制保留某些间接依赖（比如插件机制中需 dlopen 的库）
--as-needed 的生效范围是“其后出现的库”，不是全局开关
命令行顺序决定行为，这点极易被忽略。例如：
lld -shared -o libfoo.so --as-needed libbar.so libbaz.so --no-as-needed libcxx.so
含义是：
-
libbar.so：仅当其符号被libfoo.so直接引用时，才写入DT_NEEDED -
libbaz.so：同样受--as-needed约束（因为选项仍在生效） -
libcxx.so：强制写入DT_NEEDED，无论是否直接调用
性能与兼容性影响：
- 启用
--as-needed后，LLD 需在链接末期做一次符号可达性分析，对超大项目可能略增链接时间（通常可忽略） - 某些旧版 Android linker 或定制 bootloader 不严格遵循
DT_NEEDED语义，可能导致加载失败 - musl libc 默认不支持
--as-needed行为，若目标平台用 musl，需确认 LLD 构建时启用了对应后端支持
ARM Linux 平台默认禁用 --as-needed，容易踩坑
LLD 在 --target aarch64-linux-gnu 或 --arm_linux 下默认使用 --no-as-needed，和 x86_64 Linux 主流发行版行为相反。这意味着你在一个 x86_64 上验证通过的构建脚本，搬到 ARM 嵌入式环境后，可能因多出一堆 DT_NEEDED 条目，引发运行时库路径冲突或初始化顺序问题。
建议做法：
- 显式写明
--as-needed或--no-as-needed，不要依赖默认值 - 交叉编译时统一加
--target aarch64-unknown-elf（裸机）或--target aarch64-linux-gnu（Linux），并配套指定--sysroot - 用
readelf -d和ldd（后者在目标系统上运行）双查依赖链
真正容易被忽略的是：DT_NEEDED 是动态加载器读取的元数据，不是链接器“记住”的状态。一旦生成，就和构建时的选项无关了。改选项只影响这一次输出，不修复已有二进制。
