linux – 强制二进制文件使用特定(较新)版本的共享库(.so)

发布时间：2020-12-13 22:58:23 所属栏目：Linux 来源：网络整理

导读：我有一个较旧的二进制可执行文件(utserver,闭源),我试图在运行Fedora 22的系统上运行. utserver想要openssl_1.0.0 – F22提供openssl_1.0.1k 我做了两个符号链接： $sudo ln -s /usr/lib64/libssl.so.1.0.1k /usr/lib64/libssl.so.1.0.0$sudo ln -s /usr/lib

我有一个较旧的二进制可执行文件(utserver,闭源),我试图在运行Fedora 22的系统上运行.

utserver想要openssl_1.0.0 – F22提供openssl_1.0.1k

我做了两个符号链接：

$sudo ln -s /usr/lib64/libssl.so.1.0.1k /usr/lib64/libssl.so.1.0.0
$sudo ln -s /usr/lib64/libcrypto.so.1.0.1k /usr/lib64/libcrypto.so.1.0.0

但是试图运行utserver抱怨库版本：

$./utserver
./utserver: /lib64/libcrypto.so.1.0.0: version `OPENSSL_1.0.0' not found (required by ./utserver)
./utserver: /lib64/libssl.so.1.0.0: version `OPENSSL_1.0.0' not found (required by ./utserver)

好的,所以它正在寻找一个版本字符串.我编辑了utserver ELF将字符串OPENSSL_1.0.0更改为OPENSSL_1.0.1,但是我得到了同样的错误(找不到’OPENSSL_1.0.1′)

objdump和readelf都在libssl.so.1.0.1的版本区域中显示OPENSSL_1.0.1：

$objdump -p /lib64/libssl.so.1.0.1 | grep OPENSSL
3 0x00 0x066a2b21 OPENSSL_1.0.1
4 0x00 0x02b21533 OPENSSL_1.0.1_EC
0x02b21533 0x00 07 OPENSSL_1.0.1_EC

所以现在我对utserver实际检查的内容感到困惑.我怀疑它看到了OPENSSL_1.0.1_EC并且失败了.如果我在ELF中添加_EC,我会得到一个段错误,大概是因为现在我的偏移都是错误的.

$readelf -d ./utserver 
readelf: Error: Unable to seek to 0x15da90000000 for string table
readelf: Error: no .dynamic section in the dynamic segment

Dynamic section at offset 0x154fb8 contains 34 entries:

有没有办法告诉ld-linux强制加载OPENSSL_1.0.1_EC和/或修改ELF偏移的引用？非常感谢.

是的,我知道我可以在某个地方找到openssl_1.0.0的打包版本,但是如果我不需要的话,这是一个我不想恢复的库.

解决方法

Is there any way to tell ld-linux to force load OPENSSL_1.0.1_EC

没有.

符号版本已更改的原因有：旧符号和新符号不是ABI-compatible.您必须重新编译可执行文件才能使用新符号,或者(更简单)您必须提供libssl.so.1.0.0(可以是安装并与已安装的libssl.so.1.0.1k共存.

that’s one library I’d rather not revert if I don’t have to.

您不必还原任何内容(并且还原将会破坏所有需要新版本的程序).

简单地从旧包中提供libssl.so.1.0.0将使旧程序(需要它)使用该文件,而新程序(需要libssl.so.1.0.1k)将继续使用libssl.so.1.0 .1k.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!