.so补丁版本在RedHat和Ubuntu之间的差异

时间:2019-07-03 17:51:20

标签: linux shared-libraries

我在Ubuntu上构建了一个.so,它需要libssl.so(它需要libssl.so.1.0.0)。

已安装的libssl.so的实际版本是libssl.so.1.0.2k,但是有指向该文件的链接libssl.so.1.0.0,所以我想Ubuntu可以通过用{{1 }}。

如果我尝试在RHEL7上使用该.so,它将找不到它。我的RHEL7系统还安装了.0,但指向它的链接名为libssl.so.1.0.2k。我推测RHEL通过丢弃补丁版本并将主要版本和次要版本卡在一起来处理补丁版本。

我试图通过创建名为libssl.so.10libssl.so.1.0.0的链接来解决问题。对libssl.so.1.0.2klibcrypto.so.1.0.0做了同样的事情。现在我得到一些奇怪的东西:

libcrypto.so.1.0.2k

但是找到的% ldd libironoxide_java.so ./libironoxide_java.so: /lib64/libcrypto.so.1.0.0: version `OPENSSL_1.0.0' not found (required by ./libironoxide_java.so) ./libironoxide_java.so: /lib64/libssl.so.1.0.0: version `OPENSSL_1.0.0' not found (required by ./libironoxide_java.so) ./libironoxide_java.so: /lib64/libc.so.6: version `GLIBC_2.18' not found (required by ./libironoxide_java.so) linux-vdso.so.1 => (0x00007ffcfda70000) libssl.so.1.0.0 => /lib64/libssl.so.1.0.0 (0x00007fc82d0d2000) libcrypto.so.1.0.0 => /lib64/libcrypto.so.1.0.0 (0x00007fc82cc70000) ... 不需要libssl.so.1.0.0

OPENSSL_1.0.0

我在系统上找不到% objdump -p libssl.so.1.0.0 | grep SSL 3 0x00 0x066a2b21 OPENSSL_1.0.1 4 0x00 0x02b21533 OPENSSL_1.0.1_EC 5 0x00 0x066a2b22 OPENSSL_1.0.2 OPENSSL_1.0.1 0x02b21533 0x00 08 OPENSSL_1.0.1_EC 的其他任何令人困惑的实例。

有什么想法吗?还有关于构建libssl.so.1.0.0使其在Ubuntu和RHEL7上都能使用的建议?

1 个答案:

答案 0 :(得分:0)

RedHat以广泛地修改内核和库而闻名。几乎不可能将关键库改编为OpenSSL以确保与基于Debian的系统兼容。