wxl@wxl-virtual-machine:/mnt/hgfs/winshare/tools/GSNN-tools/examples$ ./run-test.bash filter1_global.s
MKDIR ../build/test
ASM filter1_global.s
../bin/gsnn-as.exe: error while loading shared libraries: libpcre.so.1: cannot open shared object file: No such file or directory
DISASM ../build/test/filter1_global.gnx
Traceback (most recent call last):
File "objdump.py", line 330, in <module>
File "objdump.py", line 245, in objdump_bproc
FileNotFoundError: [Errno 2] No such file or directory: '../build/test/filter1_global.gnx'
[23696] Failed to execute script objdump
SIM ../build/test/filter1_global.gnx
[util.c 42 @0] :load ../build/test/filter1_global.gnx: could not open
adding memory 0 0 + 0x10000000 268435456
external: added memory #0 0x0..0xfffffff
原因：无法找到名为 libpcre.so.1 的共享库文件
首先确认系统上是否已正确安装libpcre库，接着查找库文件，要注意库文件的名称可能会在系统上以不同的版本存在，例如libpcre.so.3而不是libpcre.so.1。
sudo find / -name libpcre.so.*
尝试查找其他版本的库文件，查询以后发现只有libpcre.so.3这个共享库文件，但程序依赖的是libpcre.so.1。
可以检查应用程序的依赖关系：使用
ldd命令检查你的应用程序的依赖关系，以查看它到底需要哪些库：
ldd your_application替换
your_application为你的应用程序的实际可执行文件名。这将列出应用程序依赖的所有库。确保所有依赖的库都正确安装在系统上。
可以尝试创建一个符号链接，将libpcre.so.1指向libpcre.so.3。这可以欺骗应用程序，使其认为它找到了所需的库。请注意，这可能不是最佳解决方案，因为库版本不匹配可能导致应用程序出现问题，但在某些情况下，这可以解决问题。
sudo ln -s /path/to/libpcre.so.3 /path/to/libpcre.so.1将/path/to/libpcre.so.3替换为libpcre.so.3的实际路径，将/path/to/libpcre.so.1替换为您希望创建的符号链接的路径。
其他方法：
-
升级应用程序或库：联系应用程序的开发者或维护者，了解是否有升级应用程序的版本以支持
libpcre.so.3的选项。有时，新版本的应用程序可能已经适应了新的库版本。 -
降级库版本：如果应用程序确实需要
libpcre.so.1，您可以尝试安装适当版本的libpcre库，以满足应用程序的依赖性。您可以从适用于您的Linux发行版的软件包管理器中查找并安装旧版本的库。 -
编译应用程序：如果有应用程序的源代码，可以尝试在系统上编译它，以确保它链接到正确版本的库。在编译时，您可以配置应用程序以使用
libpcre.so.3，而不是libpcre.so.1。