可执行文件中的共享库名称与文件名不同

Question

我的编译命令的清理版本看起来像gcc -o semantic_seg -Wl,-rpath,... -l:libnvrtc-5e8a26c9.so.10.1...我有一个名为libnvrtc-5e8a26c9.so.10.1的动态库文件libnvrtc-5e8a26c9.so.10.1在-rpath标志指定的目录中。 命令成功。

当我 go 运行我的程序时，它说semantic_seg: error while loading shared libraries: libnvrtc.so.10.1: cannot open shared object file: No such file or directory当我执行ldd时它显示libnvrtc.so.10.1 => not found 。

所以问题看起来像可执行文件中共享库的名称与文件名不同。 那可能是真的吗？ 名称的5e8a26c9部分是否以某种方式被剥离了？

更新：创建符号链接libnvrtc-5e8a26c9.so.10.1 -> libnvrtc.so.10.1允许可执行文件运行。 但我仍然不确定导致此名称修改发生的机制。 似乎有点魔幻。

Answer 1

那可能是真的吗？

这通常是真的。

在 ELF 系统上，linker 使用库的SONAME （如果有的话）而不是其文件名来记录运行时依赖关系。

运行readelf -d libnvrtc-5e8a26c9.so.10.1 | grep SONAME readelf -d libnvrtc-5e8a26c9.so.10.1 | grep SONAME可能会表明事实上该库确实有SONAME ，并且libnvrtc.so.10.1 SONAME

这对于外部库版本控制过去非常方便。

更新：

它允许您链接到与运行时使用的库不同的库，但我为什么要这样做呢？

就像我说的，它对于外部库版本控制和 ABI 演变很有用。

假设您发布了libfoo.so的 1.0 版。 您提供libfoo.so作为libfoo.so.1的符号链接，并将libfoo.so.1用作SONAME 。

任何与gcc main.c -lfoo链接的程序（注意：不需要有趣的-l:libfoo.so.1语法）将libfoo.so.1记录为其外部依赖项，并将在运行时使用该名称。

时间流逝，您已准备好发布不兼容 ABI 的版本 2。

您不想让所有最终用户更改他们的链接行，也不想破坏任何现有的二进制文件。

使用SONAME ，这很简单：新的 package 将包括libfoo.so.2和SONAME为libfoo.so.2 ，以及一个符号链接libfoo.so现在指向libfoo.so.2 。

瞧：两个要求都实现了：现有二进制文件继续使用libfoo.so.1 ，新链接的二进制文件使用libfoo.so.2 ，不需要Makefile更改。