项目中在运行golang编译出来的可执行程序时，出现了以下错误：
- root [ ~ ]# /mnt/main_test
- /mnt/main_test: error while loading shared libraries: libgo.so.19: cannot open shared object file: No such file or directory
一开始以为是个很小、很容易解决的问题，于是直接在网上搜索解决方法。但发现并没有人遇到同样的错误，只是有比较接近的错误，如：linux 缺少动态连接库.so--cannot open shared object file: No such file or directory
Linux error while loading shared libraries: cannot open shared object file: No such file or directory其中的解决方法并不适合本案，因此只能自行定位解决。
起初怀疑是没有相应的包导致，于是通过sudo apt install gccgo安装相应的包，问题还是存在。
又因为同组者也有使用golang编写的项目代码，她那里并未遇到这个问题。于是向她请教解决方法，她答复说需要建立工程环境才可以。按照她的解决方法，确实是可以了，程序能够正常运行起来。于是有了之前的一篇随笔文章 golang工程建立_蓝天居士的博客-CSDN博客_golang 新建项目
但是第二天在我的另一台机器上，按照昨天同样的步骤，建立工程再编译，之后放到出现错误的电脑上运行，又出现了同样的错误。一时间觉得摸不着头脑了……
冷静下来仔细思考，终于明白了问题所在，原来是这样：
我手边有两台机器，一台机器安装的是Ubuntu22.04，另一台机器安装的是自研系统。我之前写golang代码、编译都是在Ubuntu22.04这台机器上，因此编译和运行在Ubuntu的机器上是没有问题的，但是放到安装了自研系统的机器上，由于go编译器的版本不同，相应的动态库名称也就不同，当然就会出现错误。至于同事没有遇到这个问题，是因为她本身就是在自研系统的机器上编写、编译和运行golang代码的，宿主机和目标机本来就是一个系统，因此就没有出现这个问题。
将我的golang项目源码拷贝到安装自研系统的机器上编译再运行，问题就不存在了。
事情虽然不大，但是对于此类“error while loading shared libraries: libxx.xx.xx”问题提供了另一种解决思路，即关注宿主机和目标机的操作系统以及编译器版本的差异。