问题标签 [dlopen]

我想使用函数 'dlopen()' 来调用 iOS 平台上的动态库，函数 'dlopen()' 是私有 API 吗？

我有错误的共享库（未定义的符号）。

当我第一次调用 dlopen() 时，我得到一个 NULL 结果，并从 dlerror() 得到正确的错误消息。

如果我忽略错误消息并使用相同的参数调用 dlopen()，我第二次得到一个非空句柄（这表明库已成功加载）。这显然是错误的。

这个问题在 Ubuntu 11.04 下出现（IIRC，10.10 没有这个问题）。Centos 5.5 没有出现这个问题。

特别是，这个问题发生在 Tcl 解释器中。它将尝试加载共享库，首先使用规范化的绝对​​路径，如果再次失败，则使用用户提供的确切路径字符串。就我而言，两者都应该失败，但第二次调用在 Ubuntu 11.04 下错误地成功了。

奇怪的是，我只能使用我的确切生产共享库来重现这个问题。如果我制作了一个精简的共享库，它就可以正常工作。

像这样的程序足以显示我的生产库的问题：

我需要从另一个程序调用一个函数。如果另一个程序是一个库，我可以简单地使用 dlopen 和 dlsym 来获取函数的句柄。不幸的是，另一个程序是 Unix 可执行文件，并且将其构建为库不是一种选择。在可执行文件上尝试 dlopen() 会给出以下错误消息：

dlopen([...]/testprogram, 1): no suitable image found. Did find: [...]/testprogram: can't map

这并不奇怪，因为 dlopen 用于库，而不是可执行文件。有没有办法让 dlopen 和 dlsym 与可执行文件一起工作？如果没有，是否有实现相同目标的替代方法？

在我的程序中，我有如下代码

在里面/* .. */，我需要读取内存映射文件/proc/self/maps，找到libname映射到的虚拟内存地址，我还需要打开库以找到其中的某些部分。为此，我需要dlopen通过在各个位置（例如，在ldconfig缓存文件中）搜索找到的绝对名称。我怎样才能收到该文件名？

这就是我最终得到的结果（是的，这是 C++ 代码，但是 C 标记对这个问题很有意义，因为dlopen它与 C++ 和 C 一起使用，我的问题同时适用于两者，POSIX 为 C 指定了它。）。

libfile是相对/纯文件名。该映射将产生一个非普通的文件名（即不是foo.so但可能是./foo.so）。之后我用来realpath获取最终的绝对路径名。它工作得很好！

在我正在进行的项目中，我们提供了动态加载附加功能的可能性。为此，我们使用 dlopen。

为了找到这个库，我们有一些我们称之为模块路径的东西。我们有一个默认路径，共享库所在的位置（其中很多已发货）。

目前我们有两个默认路径：我们首先在构建目录中查找共享库，然后在安装目录中查找。这是因为它也应该可以在不安装的情况下运行应用程序（因此在这种情况下，它需要首先在构建目录中查找）。

现在问题来了，如果用户从源代码构建应用程序并使用 make install 安装它，则默认情况下会加载她构建目录中的库。这将导致崩溃。因此，它仅在用户随后删除或重命名构建目录时才有效。

没有问题：是否有技巧（通过 C++ 或构建系统）知道应用程序是否已安装。问题是，该功能是在共享库中实现的，搜索模块的实现方式也必须适用于链接到我们库的其他应用程序（因此我们不能依赖可执行文件的路径）。我们使用 CMake 作为构建系统。

为了使情况更加困难，该解决方案必须在 Windows、Linux 和 Mac OS X 上运行。

编辑：

我进一步调查，问题更复杂。这是这种情况：

• 有一个小的可执行文件
• 此外，还有一个“主”库 main.so
• 然后有一个动态加载的库 lib.so
• lib.so 链接到 main.so

问题是，lib.so 在其 rpath 的构建目录中具有 main.so 的绝对路径。感谢@MSalters 的提示，我现在能够进行破解以确保加载正确版本的 lib.so（安装目录中的那个），但是由于它在 rpath 中有构建路径，因此它加载了错误的 main .so （所以实际上内存中有两个 main.so 副本——这把事情搞砸了）。

有没有办法从库中删除对构建路径的引用？我尝试了与 rpath 相关的所有 cmake 选项但没有成功

我有首先加载 .dylib 的软件，让我们使用以下命令调用 libFirst.dylib：

稍后在加载的 libFirst.dylib 的函数内部，我尝试使用相同的命令加载另一个 .dylib，但对于 libSecond.dylib，此共享库的加载在我的 Xcode 控制台中给了我以下警告：

我没有得到的是它说 libFirst.dylib 没有加载，但我目前在 libFirst.dylib 的一个函数中，那么这怎么可能呢？

我在 DYLD_LIBRARY_PATH 中的所有路径也似乎正确。

在此先感谢，我已经坚持了好几天了。

我正在使用 setenv 设置 DYLD_LIBRARY_PATH，因此当我执行 dlopen() 时，它将具有找到我的 .dylib 的正确路径，但是当我执行 dlopen() 时，它似乎没有搜索我添加到 DYLD_LIBRARY_PATH 的路径。

从我可以收集到的内容中，我对 DYLD_LIBRARY_PATH 的更改在重新执行我的过程之前不会生效。它是否正确？

此外，如果这是正确的，有没有办法设置 DYLD_LIBRARY_PATH 并让我的更改工作而无需重置我的流程。

哦，是的，我在 MAC OSX 上编写了这段代码。

提前致谢。

我刚刚发现了使用 dlopen 加载 .dylib 文件的 @rpath，并且需要一些帮助来理解它们。我在 OSX 机器上使用 Xcode 3.2.5。

我有几个 .dylib 调用其他 .dylib，它们也互相调用。@rpath 似乎适用于加载的初始 .dylib，但是一旦我使用另一个 .dylib 进行 dlopen 调用，该 .dylib 使用先前使用 @rpath 找到并加载的第一个 .dyblib 文件，dlopen 将失败，说它可以'找不到原始的.dylib。

@rpath 是否仅适用于与 dlopen 一起使用的文件，还是也用于解决正在打开的 dylib 文件内部的依赖关系？

更新：

我的进一步发现导致我使用 install_name_tools 来更改相互依赖关系以拥有它们的@rpath。这是这样做的正确方法吗？

我有一个应用程序，它由相当多的共享库组成。我已经为其中一些编写了 perl 扩展。此外，我已将 perl 嵌入到应用程序中。

我正在用 C++ 调用 perl 脚本。可以说，我的 perl 扩展名为 SV::Net::Info 和 SV::Interface，我的 perl 文件看起来像这样

我能够从 C++ 读取 perl 脚本并将输出发送回 C++，没有任何问题。当我取消注释第三行时出现问题，use IO::Socket;我收到错误消息说

这是因为 IO 本身就是一个 C 库。我已经添加了这里提到的 xs-glue 。它没有解决我的问题，因为添加的胶水正在寻找 boot_IO 符号（在 IO.so 文件中定义）。我无法将我的应用程序与 IO.so 链接，因为它是一个文件，perl 在运行时使用 dlopen 打开该文件。（另外，我的应用程序应该在 windows 上运行，windows 只提供 .dll 文件而不提供 .lib 文件）。出路是什么？

我正在考虑编写一个包装函数 boot_IO，它在运行时使用 dlopen 从 IO.so 运行实际的 boot_IO 函数。这是唯一的选择吗？

有人可以帮我知道如何使用 dlopen 来处理 libc 内存分配函数吗？尤其是像搜索 libc 路径然后获取句柄之类的东西。应该使用哪些模式来调用 dlsym？

想法是：

1. 搜索 libc 路径
2. 在它上面调用 dlopen
3. 使用 dlsym 访问内存函数（malloc、calloc 等）和
4. 使用函数

请帮助我提供上述 4 个步骤的代码片段。