linux下无法用ldconfig查库版本，因其仅管理路径缓存；真实版本需用strings提取二进制中的字符串（如strings libssl.so.1.1|grep openssl）或通过包管理器查询（如dpkg -s或rpm -qf）。
Linux 下无法直接用 ldconfig 查看某个静态库或动态库的版本号 —— 它压根不存版本信息，只管缓存和路径映射。
ldconfig -p 显示的是符号链接目标，不是版本号
ldconfig -p 列出的是当前动态链接器缓存中已注册的共享库名称（如 libc.so.6）及其实际路径（如 /lib64/libc-2.17.so），但这个路径名里带的数字不一定是“版本号”，只是 soname 编码惯例。比如 libssl.so.1.1 中的 1.1 是 ABI 兼容标识，不是 OpenSSL 的发布版本（如 1.1.1w）。盲目把 soname 当版本会误判。
- 运行
ldconfig -p | grep libssl可能输出：libssl.so.1.1 (libc6,x86-64) => /lib/x86_64-linux-gnu/libssl.so.1.1 - 真实版本得查这个文件本身：
objdump -p /lib/x86_64-linux-gnu/libssl.so.1.1 | grep NEEDED或更直接：strings /lib/x86_64-linux-gnu/libssl.so.1.1 | grep "OpenSSL " -
ldconfig不解析 ELF 元数据，也不读取包管理器数据库，它只是个路径注册器
查动态库真实版本的可靠方式：strings + 特征字符串
大多数主流库（如 OpenSSL、zlib、libcurl）在编译时会把版本字符串写进二进制段里，strings 能快速捞出来。这是最轻量、跨发行版、不依赖包管理器的方法。
- 先定位库文件：
find /usr -name "libssl.so*" 2>/dev/null | head -n1 - 再提取版本：
strings /usr/lib/x86_64-linux-gnu/libssl.so.1.1 | grep -E "(OpenSSL|LibreSSL) [0-9]" | head -n1 - 对 zlib：
strings /usr/lib/x86_64-linux-gnu/libz.so.1 | grep "zlib " | head -n1 - 注意：有些精简版或自编译库可能删掉了字符串表，这时需回退到包管理器查询（见下一条）
通过包管理器反查（最准，但依赖安装来源）
如果你的库是通过 apt、yum 或 dnf 安装的，版本信息一定在包元数据里。这是唯一能拿到「发布版本号」（如 openssl-1.1.1w-0+deb11u4）的途径。
- Debian/Ubuntu：
dpkg -S /usr/lib/x86_64-linux-gnu/libssl.so.1.1得到包名，再dpkg -l 'libssl1.1' - RHEL/CentOS：
rpm -qf /usr/lib64/libssl.so.1.1→rpm -qi openssl-libs - 注意：若库是手动
make install的，包管理器查不到，必须用strings或源码里的VERSION文件
为什么不能依赖 /usr/lib/libxxx.so.xxx 的文件名？
文件名中的数字（如 libpng16.so.16）是 soname，由构建时的 -Wl,-soname 指定，仅表示 ABI 兼容层级。同一 soname 下可能有多个发布版本（如 libpng 1.6.37 和 1.6.43 都用 libpng16.so.16），而不同 soname 也可能对应同一发布分支（如从 1.6.x 升级到 1.7.x 才改 soname）。硬编码文件名做版本判断，在自动化脚本里极易出错。
真正需要版本号的场景（比如兼容性校验、漏洞排查），必须落到具体构建标识或包版本上；只靠 ldconfig 或文件名，等于拿路标当目的地。
