解决cleos在Ubuntu 22.04上找不到依赖库的问题

在之前折腾系统升级的过程中,我发现一个问题,测试机升级至Ubuntu 22.04 LTS后,老版本的cleos无法执行。

image.png
(图源 :pixabay)

cleos出错

出错系统如下:

cleos: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory

后来经过检查,其实不光是cleos,我本地再跑的一个EOS节点(nodeos)也无法运行啦。其中cleos是v2.0.12,而nodeos,则是v3.1.0(Leap v3.1)。

使用ldd查看cleos的依赖:

Capture_cleos.PNG

我尝试在Ubuntu 20.04上重新编译Leap,发现cleos依然是依赖libssl.so.1.1:

Capture_cleos(20.04).PNG

所以依旧无法运行起来。

临时解决方法

通过Google搜索,发现这种情况是OpenSSL版本不兼容导致的。Ubuntu 22.04上的OpenSSL版本如下:

OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)

而Ubuntu 18.04上的OpenSSL版本是:

OpenSSL 1.1.1 11 Sep 2018

一种解决方法是编译安装旧版本的OpenSSL,用脚趾头想,都知道这样做是不靠谱的。

网上还有一些说法是这种情况是openssl库位置不正确,解决方法是查找到相关文件,复制到对应目录下,再建立软链接。不过显然我遇到的不是这种情况。

我尝试从其它主机上复制对应文件到测试机下,cleos以及nodeos竟然都可以神奇地运行起来,不过显然这也不是什么最佳解决方案。

Ubuntu 22.04 LTS下重新编译Leap

后来折腾hived的时候,我将编译机(VPS) 升级到Ubuntu 22.04 LTS,然后我又注意到Leap这两天连发了N个版本,最新发布版是v3.1.2。

那么或许一劳永逸的方法是在Ubuntu 22.04 LTS下重新编译Leap的最新版,再拿到测试机上运行。这样编译环境和运行环境都一样,总不会再有问题了吧?

于是重新编译Leap V3.1.2,除了慢,一切都还算顺利:

image.png

这时再查看cleos的依赖,显示如下信息:

Capture_cleos(build.22.04).png

重新运行cleos以及nodeos

将编译出来的最新版本(Leap v3.1.2)的运行目录(bin),复制到测试机上,并执行,发现一切都正常。

所以,偷懒是不可取的。要让各种程序都稳定运行,最后就是在相同的环境下编译和运行。

另外一个感慨就是Leap 最近版本更新有点频繁啊,就在两天前,又发布了Leap v3.2.0-rc1,这难道就是团队在做事,等归零拉盘?真心希望所有的虚拟币,尤其是石墨烯系的币都狠狠地拉上一波。

不过没心思去研究Leap 3.2都更新了些啥,毕竟HIVE 的HF26就要启动啦,现在一堆要学要测的内容呢。至于编译Leap,不过是随手而为,毕竟都是机器在做,也不浪费我啥时间,哈哈哈。

相关链接

H2
H3
H4
3 columns
2 columns
1 column
Join the conversation now
Logo
Center