C:如何同时链接到不同的库版本

我生成一个动态库（

libfoo.so

）需要

libcrypto.so

。 它在构建平台中运行良好（我在Ubuntu 16.04中构建）。但是，当我将同一个库移动到Debian Stretch 9.3时，它开始抱怨缺少

libcrypto.so.1.0.0

。openssl包安装在Debian Stretch中，但是

libcrypto.so

被命名为

libcrypto.so.1.0.2

。 经过一番挖掘，我发现尽管 Ubuntu 16.04上的

libcrypto.so

被命名为

libcrypto.so.1.0.0

（其

SONAME

也

libcrypto.so.1.0.0

），它实际上是1.0.2版

问题是：我不想为Debian重新编译一个特殊版本，我的库是否可以在两个Linux发行版上使用？或者两者都链接。那么，是同时使用版本，还是使用其他方法

忘了提到，我使用了gcc编译器，我的库是用C编写的。

在我看来（尽管我以前没有这样做过）。。。如果您不太担心共享对象libfoo.so的大小。。。我认为您最好的选择是静态链接libcrypto.a（您选择的libcrypto的静态版本）

尽管我怀疑您可能会遇到其他c库在不同的发行版（Debian和Ubuntu）之间表现不佳。。。即使你要让它工作，维护也将是一场噩梦

（如果在运行时将.so对象加载到另一台机器上编译的程序中，下面的内容可能与此无关）

即使要完全静态链接二进制文件。。。这可能行不通

对于任何比静态链接的hello world更复杂的事物，答案可能是否定的。 如果不在分布X上进行测试，假设X的答案是否定的

---

我找到了一个解决这个问题的方法

我制作了

libcrypto.so.1.0.0的本地副本，并使用
patchelf
更改其
SONAME

patchelf --set-soname libcrypto.so libcrypto.so.1.0.0

然后构建我的库并链接到本地副本，而不是系统库，它将显示为
需要的libcrypto.so
，而不是以前的
需要的libcrypto.so.1.0.0
，并且它能够在Debian和Ubuntu上工作

但对于其他发行版，用户可能需要确保
libcrypto.so
存在，或者他们必须创建一个指向
libcrypto.so.1.x.x
您链接的librcrypto是什么？尝试libcrypto.so.1，它应该指向libcrypto 1.0.2或1.0.0，具体取决于系统。（不过，为每个linux发行版重建仍然是明智的做法）。最简单的方法是将libcrypto与您的软件一起发布（将其与您的可执行文件放在同一目录中）@dbrank0，谢谢，我会尝试一下。通常我只做gcc-lcrypto，它会找到libcrypto.so，在我的例子中它是libcrypto.so.1.0.0的符号链接。（或Debian中的libcrypto.so.1.0.2）@mnistic我以前就想到过，但在我看来这听起来有点傻，因为我在libcrypto.so中使用的函数与特定版本没有紧密联系，理论上，它可以与任何libcrypto.so一起工作。我只需要找到一个很好的方法来解决（在我看来）链接问题。谢谢，我认为目前它可能是解决这个问题的唯一可能的选择，而不必为每个受支持的发行版重新编译。@cityzz我以前做过这件事，在处理OpenSSL时，跨Linux发行版的可移植性非常需要静态链接
libcrypto
和
libssl
。在过去几年中，OpenSSL中的API发生了重大变化，并且不能保证您在任何发行版上都能找到一个有效的匹配项。@AndrewHenle感谢您的建议，这也是我的想法和解决方案。它只是编译，还是你可以在没有segfault的情况下使用函数？@Hedge7707我可以在没有segfault的情况下正确使用我的函数，这可能是一个特例，因为ubuntu上的libcrypto.so.1.0.0与libcrypto.so.1.0.2（一个是版本1.0.2h，另一个是版本1.0.2l）相似。而且我只在库中使用非常简单的函数，没有任何特定于1.0.2版的内容。@Hedge7707我在这里写的答案只是提供另一种想法，它可能不适用于生产代码。我认为你的答案在这个意义上更好。哈哈，你的答案很好！我只是好奇，因为我认为libc和其他动态链接到libcrypto.so的库之间可能存在冲突。。。但我想我找到了一个解决这个问题的方法。你真的不想这么做。静态链接
libcrypto
并不难。要从“这个产品是垃圾”的感觉中恢复过来真的很难，因为即使它能够在您今天可以访问的Debian和Ubuntu安装上工作，明年也不一定能在其他人的安装上工作。