递归共享库加载-无法打开共享对象文件

Recursive shared library loading - Cannot open shared object file

本文关键字：共享 文件 对象 加载 递归      更新时间：2023-10-16

我正在编译一个由几个项目组成的应用程序，这些项目生成动态库(LINUX上的共享库(。当然，不同的项目正在链接到我编译的其他项目。我在Ubuntu下使用CodeBlocks 10，使用GCC编译器。

由于事实上，根据用户指定的参数，应加载不同的库，在我的主要应用程序中，我正在根据决定加载适当的库，如下所示：

dll = dlopen("my_library.so", RTLD_LAZY);

如文档中所述，如果库依赖于其他共享库，并且该过程是递归完成的，则dlopen会自动加载库。

问题是，在我的dlopen之后，我立即调用dlerr((来了解发生了什么，我得到了以下错误：

../../..//gccDebug/os.so:无法打开共享对象文件：没有这样的文件文件或目录。

只要看一下这个错误，我就完全理解了，因为它在下面找的2个文件夹比它应该找的多。问题是为什么？

我的意思是：我使用相对路径在项目上显式加载共享库。在我的主应用程序上，工作目录是..//gccDebug。我使用dlopen加载mylibrary.so，它显式加载(在项目选项中(..//gccDebug/gi.so。然后此gui.so也显式加载(在项目选项中(..//gccDebug/so.os

在我看来，正在发生的事情是，他正在添加路径，使得在第三次"迭代"时，他正在寻找一个已经搜索了太多文件夹的路径。如果第一次递归加载(gui.so(运行良好，为什么第二次递归加载会给出一条奇怪的路径？？

使用dlopen函数递归加载共享库有什么问题？

每个路径都应该相对于进行加载的库，因此../../gccDebug/gui.so要在同一目录中加载某些内容，就应该加载./gui.so

额外的../..是因为你已经告诉../../gccDebug中的某个东西在../..中加载某个东西/gccDebug _relative to itself_ which relative to your program's working directory is.//gccDebug/..//gccDebug i.e../..//gccDebug`

对于不同的库，这样做几次，就会得到您看到的不需要的..组件的数量。

你确定gui.so真的加载了吗？可能是mylibrary.so在链接时从gui.so复制了../../gccDebug/os.so依赖项，所以在运行时试图在加载gui.so之前加载它吗？

你有没有用ldd mylibrary.so看看它试图找到什么？您也可以使用readelf -d mylibrary.so来查看库的动态部分的内容。

相关文章：