为什么linux ld somtime使用libs的符号链接答案

【问题标题】：Why linux ld somtime use the symbolic link of libs为什么linux ld somtime使用libs的符号链接
【发布时间】：2021-02-12 15:58:05
【问题描述】：

我在我的 linux cli 工具中使用 jsoncpp 库。

CMakeLists.txt 包含

find_library(LIB_JSON jsoncpp)
target_link_libraries(${PROJECT_NAME} ${LIB_JSON})

结果是

/usr/bin/c++ -rdynamic CMakeFiles/cktwagent.dir/agent_main.cpp.o -o cktwagent -ljsoncpp

当我检查我找到的二进制文件时：

 $> ldd cktwagent 
    linux-vdso.so.1 (0x00007ffe4cfd1000)
    libjsoncpp.so.24 => /usr/lib/libjsoncpp.so.24 (0x00007f87505bd000)
    libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f87503e0000)
    libm.so.6 => /usr/lib/libm.so.6 (0x00007f875029a000)
    libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f8750280000)
    libc.so.6 => /usr/lib/libc.so.6 (0x00007f87500b7000)
    /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f87506ce000)

为什么要使用 /usr/lib/libjsoncpp.so.24 而不是符号链接 /usr/lib/libjsoncpp.so？

为什么 ld 有时会解析到真正库文件的库链接？

$> ls -l /usr/lib/libjsoncpp.so
lrwxrwxrwx 1 root root 16 26. Sep 17:02 /usr/lib/libjsoncpp.so -> libjsoncpp.so.24

如果是 /usr/lib/libstdc++.so.6，ld 使用符号链接。当我检查 ldd 输出的路径时，libstdc++.so.6 指向一个符号链接。

$> ls -l /usr/lib/libstdc++.so.6
lrwxrwxrwx 1 root root 19  9. Nov 12:43 /usr/lib/libstdc++.so.6 -> libstdc++.so.6.0.28

我喜欢理解这种行为。因为当我将二进制文件复制到不同的系统时，libjsoncpp.so 的链接可用。但它指向一些不同的版本。

非常感谢

托马斯

【问题讨论】：

符号链接与 ABI 版本控制有关，如 How To Write Shared Libraries section 3.3 中所述。

标签： c++ linux ld

【解决方案1】：

这是一个版本兼容性功能。按照惯例，API 兼容性由主要版本号决定。所以6.0.28 将与6.1.1 兼容，但与5.0.1 或7.0.1 不兼容。

为了兼容升级，libstdc++.so.6.0.28 符号链接为libstdc++.so.6。然后它可以二进制升级到例如libstdc++.so.6.0.29 不涉及依赖于 API 版本 6 的 libstdc++ 的应用程序。

此外，它允许具有不同主要版本号的库在同一系统上共存。安装libstdc++.so.7.0.0 不会破坏链接到libstdc++.so.6 的应用程序。

为什么要使用/usr/lib/libjsoncpp.so.24 而不是符号链接/usr/lib/libjsoncpp.so？

这是因为 libjsoncpp 的 soname 为 libjsoncpp.so.24。显然，它遵循由主要版本号确定兼容性的相同约定。

如果您像这样链接共享库libfoo，您可以实现相同的行为：

gcc -shared -Wl,-soname,libfoo.so.<major> -o libfoo.so.<major>.<minor>

更多详情请参考GCC Howto - Version numbering, sonames and symlinks。

【讨论】：