ldd命令用于查看可执行文件或共享库运行时依赖的动态链接库，输出中“=>”左侧为库名、右侧为实际路径，出现“not found”表示缺失；安全替代方案是readelf -d binary | grep needed或objdump -p binary | grep needed，二者不执行代码、不受权限和架构限制。
在银河麒麟系统中准确获知某个可执行文件或共享库运行时实际加载哪些动态链接库，是排查程序启动失败、缺失.so文件或跨架构兼容问题的关键前提。
用ldd查看可执行文件的动态库依赖
ldd是最常用且直观的工具，它模拟动态链接器行为，直接列出所有已解析的依赖路径。
在终端中执行：ldd /path/to/executable，例如 ldd /usr/bin/filezilla。
注意观察输出中的not found条目——这表示该库名虽被声明依赖，但未在/etc/ld.so.cache、LD_LIBRARY_PATH或默认路径（如/lib、/usr/lib）中定位到对应文件。
【必须确保目标文件是合法ELF格式】：若提示“not a dynamic executable”，先用file /path/to/executable确认类型；脚本、Python字节码或损坏二进制会直接导致ldd失效。
安全替代方案：readelf和objdump
当目标文件不可信、权限受限或需绕过ldd的潜在执行风险时，应改用静态解析方式。
方法一：使用readelf读取动态段信息
执行：readelf -d /path/to/executable | grep NEEDED。
该命令仅解析ELF结构，不加载任何代码，输出格式为：0x0000000000000001(NEEDED) Shared library: [libwx_baseu-3.2.so.0]。
方法二：使用objdump提取依赖项
执行：objdump -p /path/to/executable | grep NEEDED。
结果更简洁，仅显示库名，如NEEDED libstdc++.so.6。
这两个命令对无执行权限的.so文件也完全有效，无需临时加x位，规避了ldd的安全隐患。
处理无权限或非本机架构的共享库
第一步：确认文件属性与架构
运行file /path/to/library.so，检查是否为ELF格式及目标架构（如x86-64、aarch64）。若输出含“data”或“cannot open”，说明不是可解析的动态库。
第二步：对无执行权限的.so文件强制解析
若ldd报错“not a dynamic executable”，优先用readelf -d /path/to/library.so | grep NEEDED；此操作不依赖文件权限，也不触发任何代码执行。
第三步：交叉环境适配
若目标库为ARM64而当前系统为x86-64，【禁止直接运行ldd】，因其调用的宿主机解释器无法加载异构二进制，会导致崩溃或误报。此时必须使用readelf或objdump，它们纯静态解析，不受架构限制。
