今天实验室的博士在进行数模混合仿真的时候，报错了，错误如下：

Failed to load dynamic library libadsptolemy_vpi
  libadsptolemy_vpi.so: cannot open shared object file: No such file or directory or file is not valid ELFCLASS64 library.
	Elaborating the design hierarchy:
   parameter p_spi =  `SPI_63*64'h8000000000000000

依据错误提示，应该是libadsptolemy_vpi.so读取错误了。其出现错误有三种可能，文件不存在，目录不存在，或者是不是一个合法的ELFCLASS64库。首先我们先找一下这个文件是在哪里的，搜索一下，是在/eda/agilent/ADS2011_10/adsptolemy/lib.linux_x86下的，x86的目录，说明这个动态库是ELFCLASS32的，所以问题出在了这个.so不是一个ELFCLASS64上。

这里可以选说一下.so文件是什么，摘抄一下网友对些的理解：

linux下何谓.so文件：1. 用过windows的同学应该都知道 .dll文件吧, 这二者有什么共通之处呢,其实 .so文件就跟.dll文件差不多.
2.一般来说.so文件就是常说的动态链接库, 都是C或C++编译出来的。与Java比较就是：它通常是用的Class文件（字节码）.
3.Linux下的.so文件时不能直接运行的,一般来讲,.so文件称为共享库.
4.那么.so文件是怎么用的呢？
for example：(1)动态库的编译
这里有一个头文件：so_test.h，三个.c文件：test_a.c、test_b.c、test_c.c，我们将这几个文件编译成一个动态库：libtest.so。
命令：$ gcc test_a.c test_b.c test_c.c -fPIC -shared -o libtest.so
（参考2：都是由C或C++编译出来的）
（-shared 该选项指定生成动态连接库（让连接器生成T类型的导出符号表，有时候也生成弱连接W类型的导出符号），不用该标志外部程序无法连接。相当于一个可执行文件）
（-fPIC：表示编译为位置独立的代码，不用此选项的话编译后的代码是位置相关的所以动态载入时是通过代码拷贝的方式来满足不同进程的需要，而不能达到真正代码段共享的目的。）
(2)动态库的链接
这里有个程序源文件 test.c 与动态库 libtest.so 链接生成执行文件 test：
命令：$ gcc test.c -L. -ltest -o test
（注：测试是否动态连接，如果列出libtest.so，那么应该是连接正常了）
（-L.：表示要连接的库在当前目录中）
（-ltest：编译器查找动态连接库时有隐含的命名规则，即在给出的名字前面加上lib，后面加上.so来确定库的名称）
命令：$ ldd test
（注：执行test，可以看到它是如何调用动态库中的函数的。）

所以对于.so的最简单的理解可以相对于Windows的DLL文件。查看文件属性的话可以使用如下命令：

1、64位linux系统可以运行32位和64位程序，32位系统只能运行32位程序
2、file filename可以检查这个文件是32位还是64位
3、ldd filename可以检查这个文件需要哪些依赖库文件，可能依赖的库文件libG4processes.so是32位

如果我们把ads目录下的32的.so拷贝到x86_64下面，就什么报：

SYSTEM ERROR:   VPI       LOADFL
         Failed to load dynamic library libadsptolemy_vpi
  libadsptolemy_vpi.so: wrong ELF class: ELFCLASS32

说白了也就是同一问题。而CentOS64位是支持32位的。

未经允许不得转载：TacuLee » AMS数模混合仿真时遇到libadsptolemy_vpi.so读取错误