我的库 A 依赖于外部库 B。当我在 A.so 上使用 ld 时，我看到 B 链接为 B.so.10，但在我的计算机上链接是：
B.so -> B.so.10
B.so.10 -> B.so.10.5
我正在尝试创建一个指向 JUST B.so 的链接，并使用符号链接来加载要加载的版本。我对 A.so 进行了十六进制编辑，并用 B.so 替换了 B.so.10 的所有发现，并且 ld 链接它就好了，但是当我尝试 dlopen A.so 时，它说：'加载 A.so 时出错：版本 B。所以找不到'我已经阅读了有关符号版本控制等的信息，但老实说不知道在哪里寻找会导致问题的原因？
我检查了 readelf 并将未编辑的版本与我的进行了比较，除了 SO 名称之外，我在差异中看不到任何内容。 Elfedit 也不起作用，只是将二进制文件变成了垃圾数据。
【问题讨论】：
标签： linux hex shared-libraries elf dlopen
如果您运行readelf -V B.so，您可能会发现它没有定义版本B.so，但确实定义了版本B.so.10。
通过用B.so 替换所有B.so.10 字符串，您向运行时加载程序声明A.so 依赖于版本B.so，而不是它过去依赖的B.so.10。
由于在运行时不存在这样的版本，加载程序正确地抱怨。
我检查了 readelf 并将未编辑的版本与我的进行了比较，除了 SO 名称之外，我在差异中看不到任何内容。
再次检查。特别是，这样做：
diff <(readelf -V A.so.orig) <(readelf -V A.so)
您应该看到那里的一些差异。
我正在尝试创建一个指向 JUST B.so 的链接，并使用符号链接来加载要加载的版本。
您似乎有一个XY problem。您真正想达到什么目的？
更新：
最初的问题是我试图让我的软件 CUDA 版本不可知。 ...即使 ABI 并没有永远改变，我也不能把这个二进制文件放在另一个具有不同 cufft 版本的系统上，因为 cufft 链接到特定版本。
啊，你确实实际上有一个XY问题。
你不能事实上推断ABI没有改变，除非你验证每个结构可能在那个中使用ABI 没有改变（这不同于验证 API 没有改变，而您可能已经这样做了）。
如果您成功修补了版本，最终结果可能是在具有不同版本 CUFFT 的系统上发生神秘崩溃。
如果你幸运的话，崩溃会快速且可重复地发生。如果你不走运，它会很少发生，并且看起来完全神秘且不相关，只会发生在某些系统上，只会发生在某些客户机器上，只有在你对库进行完全不相关的更改后才会发生，等等。
TL;DR：你让自己承受巨大的痛苦。只是不要这样做。
【讨论】：