重新提出的问题(尽管它已经被解决):
我一直在使用dlopen(3)在Linux上加载共享对象库时遇到问题。该库是由我构建的一组系统库的一部分,所有这些库都由一个中央可执行文件在运行时加载。所有这些都组织在Code::Blocks中的单个工作区中,其中每个项目都在名为Source的目录中拥有自己的文件夹,该目录将随程序一起发布。可执行文件的构建目录与其自身源代码相隔两个目录,因此可执行文件和Source文件夹位于同一个目录中。库也构建到与可执行文件相同的目录中,因此我按如下所示传递了我要打开的库的名称:
int main(int argc, char** argv) {
void* hLibrary = dlopen("libLibrary.so", RTLD_NOW | RTLD_GLOBAL);
if(hLibrary == NULL) {
fprintf(stderr, "%s\n", dlerror());
return 1;
}
return 0;
}
这曾经在构建目录与源代码相同时工作过,直到我调整了源代码的目录结构以符合上述安排。此时问题在于dlerror()返回“无法打开libLibrary.so:没有这样的文件或目录”,尽管该文件明显存在并且与可执行文件位于同一目录中。然后我尝试传递“/libLibrary.so”,因为根据dlopen(3)手册页,添加“/”表示相对目录。这返回了相同的错误。
解决方案是需要一个“./” - 其中“.”表示可执行文件的工作目录 - 并且Code :: Blocks中的工作目录需要更改为构建可执行文件的位置。以下内容完美地解决了这个问题:
void* hLibrary = dlopen("./libLibrary.so", RTLD_NOW | RTLD_GLOBAL);
这并没有完全展示解决方案,但以下基本上就是我所做的等价物:
void* hLibrary = dlopen("./../../libLibrary.so", RTLD_NOW | RTLD_GLOBAL);
希望这能更好地解释情况。