在之前折腾系统升级的过程中，我发现一个问题，测试机升级至Ubuntu 22.04 LTS后，老版本的cleos无法执行。
(图源 ：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的依赖：
我尝试在Ubuntu 20.04上重新编译Leap，发现cleos依然是依赖libssl.so.1.1：
所以依旧无法运行起来。
临时解决方法
通过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，除了慢，一切都还算顺利：
这时再查看cleos的依赖，显示如下信息：
重新运行cleos以及nodeos
将编译出来的最新版本(Leap v3.1.2)的运行目录(bin)，复制到测试机上，并执行，发现一切都正常。
所以，偷懒是不可取的。要让各种程序都稳定运行，最后就是在相同的环境下编译和运行。
另外一个感慨就是Leap 最近版本更新有点频繁啊，就在两天前，又发布了Leap v3.2.0-rc1，这难道就是团队在做事，等归零拉盘？真心希望所有的虚拟币，尤其是石墨烯系的币都狠狠地拉上一波。
不过没心思去研究Leap 3.2都更新了些啥，毕竟HIVE 的HF26就要启动啦，现在一堆要学要测的内容呢。至于编译Leap，不过是随手而为，毕竟都是机器在做，也不浪费我啥时间，哈哈哈。