ldd本身不显示动态库的版本号，仅解析DT_NEEDED条目并显示库名与路径；需结合/lib64/libc.so.6直接执行、getconf GNU_LIBC_VERSION或readelf -V等方法获取实际版本信息。
ldd 输出里根本看不到动态库的版本号
直接运行 ldd 命令（比如 ldd /bin/ls）只会显示库名和它实际链接到的文件路径，例如 libc.so.6 => /lib64/libc.so.6，但不会告诉你这个 libc.so.6 是 2.31 还是 2.35。这不是 bug，是设计如此 —— ldd 只解析 ELF 的 DT_NEEDED 条目，不读取库内部的版本符号或 soname 版本字段。
真正能查到版本号的三个可靠方法
必须跳出 ldd 单一命令的思维，转向组合操作：
- 对
ldd输出中右边的完整路径（如/lib64/libc.so.6），直接执行它：/lib64/libc.so.6—— 多数 GNU libc 会直接打印版本信息（如GNU C Library (GNU libc) stable release version 2.35） - 用
getconf GNU_LIBC_VERSION快速获知系统默认 glibc 版本（注意：这只反映当前环境的主 libc，不能代替具体库的版本） - 对任意
.so文件，用readelf -V或objdump -T查看其符号版本定义（较重，适合调试兼容性问题），例如：readelf -V /lib64/libc.so.6 | grep GLIBC_
为什么不能只靠 ldd --version 或 ldd -v
ldd --version 显示的是 ldd 工具自身的版本，不是被检查程序所依赖库的版本；ldd -v 虽然会列出每个库的详细依赖链和符号版本节（Version definition section）信息，但它**不解析或展示库文件自身的实现版本号**，只告诉你“这个库声明支持哪些符号版本”，比如 GLIBC_2.2.5、GLIBC_2.34 —— 这是接口兼容性标识，不是构建时的版本字符串。
容易被忽略的关键点
动态库的“版本”其实有两层含义：一是 soname 中体现的 ABI 兼容层级（如 libc.so.6 表示与 libc 6.x 兼容），二是构建时嵌入的实际发行版本（如 2.35）。前者决定能否加载，后者影响具体函数行为。很多线上故障源于两者错配 —— 比如程序在 glibc 2.28 上编译，却在 2.35 环境运行，某些新引入的符号可能未被识别。这时候光看 ldd 输出一切正常，但运行时报 undefined symbol，必须用 readelf -d 对比 DT_SONAME 和 DT_VERDEF 才能定位。
