rdmacm.so:无法打开共享对象文件。但是,文件存在于库路径中

时间:2012-12-14 03:09:15

标签: c linux rdma

我有一个程序使用infiniband rdmacm库rdmacm.so

在一台计算机(Ubuntu服务器)上,我可以毫无问题地运行它。 在我的开发PC(Ubuntu桌面版)上,我得到:

  

./测试的客户端   rdmacm.so:无法打开共享对象文件:没有这样的文件或目录

这是我被难倒的地方。

ldd rdma-client

linux-vdso.so.1 =>  (0x00007fffdb62b000)
libibverbs.so.1 => /usr/lib/libibverbs.so.1 (0x00007f97ca007000)
librdmacm.so.1 => /usr/lib/librdmacm.so.1 (0x00007f97c9dfe000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f97c9a3e000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f97c9821000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f97c961d000)
/lib64/ld-linux-x86-64.so.2 (0x00007f97ca237000)

cat /etc/ld.so.conf

include /etc/ld.so.conf.d/*.conf

cat /etc/ld.so.conf.d / * .conf

# Multiarch support
/lib/i386-linux-gnu
/usr/lib/i386-linux-gnu
/lib/i686-linux-gnu
/usr/lib/i686-linux-gnu
# libc default configuration
/usr/local/lib
# Multiarch support
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu
/usr/lib/fglrx
/usr/lib32/fglrx
# Legacy biarch compatibility support
/lib32
/usr/lib32

ls -l / usr / lib / librdmacm *

-rw-r--r-- 1 root root 41146 Jul 19  2011 /usr/lib/librdmacm.a
lrwxrwxrwx 1 root root    18 Jul 19  2011 /usr/lib/librdmacm.so -> librdmacm.so.1.0.0
lrwxrwxrwx 1 root root    18 Jul 19  2011 /usr/lib/librdmacm.so.1 -> librdmacm.so.1.0.0
-rw-r--r-- 1 root root 35248 Jul 19  2011 /usr/lib/librdmacm.so.1.0.0

一切看起来都很正确。为什么我不能运行test-client。


修改

我正在使用的代码来自geekinthecorner博客。 Infiniband测试应用程序。

在客户端,它有几个dlopen调用:

即。

void *handle = dlopen("rdmacm.so", RTLD_LAZY);
...  
handle = dlopen("ibverbs.so", RTLD_LAZY);

这适用于ubuntu服务器。但是在我的开发桌面计算机上,它找不到库。

如果我将库重命名为喜欢这个

void *handle = dlopen("librdmacm.so", RTLD_LAZY);
...  
handle = dlopen("libibverbs.so", RTLD_LAZY);

他们被发现了。 dlopen不会自动添加“lib”吗?我假设在我的服务器上必须是这样的,因为没有这个库就找到了。

无论如何,我不确定我是否需要这些dlopen调用。我可以完全删除它们,程序也可以。但是,现在我很好奇为什么dlopen在两台机器上的表现不同,因为路径和/etc/ld.so.conf设置包含相同的搜索路径。

1 个答案:

答案 0 :(得分:1)

void *dlopen(const char *filename, int flag);

dlopen()加载由以null结尾的字符串filename命名的动态库文件,并为动态库返回一个不透明的“句柄”。如果库依赖于其他共享库,那么动态链接器也会以递归方式自动加载这些库。 因此,无论如何,标准dlopen()将永远不会对filename字符串进行前置或修改。

以下列方式搜索指定的文件名:

  • (仅限ELF)如果调用程序的可执行文件包含DT_RPATH标记,且不包含DT_RUNPATH标记,则DT_RPATH中列出的目录搜索标签。

  • 如果在程序启动时,环境变量LD_LIBRARY_PATH被定义为包含以冒号分隔的目录列表,则会搜索这些目录。 (作为安全措施,set-user-ID和set-group-ID程序将忽略此变量。)

  • (仅限ELF)如果调用程序的可执行文件包含DT_RUNPATH标记,则会搜索该标记中列出的目录。

  • 检查缓存文件/etc/ld.so.cache(由ldconfig(8)维护)以查看它是否包含文件名条目。

  • 搜索目录/lib/usr/lib(按此顺序)。

因此,您注意到dlopen()的这种奇怪行为可能是由于库librdmacm.solibibverbs.so的现有符号链接/硬链接为rdmacm.so和{{1} },在任何上述库搜索路径中。

如果ibverbs.so因任何原因失败,则返回NULL。在使用dlopen()返回的句柄之前检查NULL。

dlopen

参考:handle = dlopen("libxyz.so", RTLD_LAZY); if (!handle) { fprintf(stderr, "%s\n", dlerror()); exit(EXIT_FAILURE); }