问题标签 [dlopen]

我在我正在编写的 Apache 模块中使用 dlopen() 以便我可以为我的模块提供一个插件系统。我发现，如果我编译我的模块，编译我的插件，然后启动 Apache，一切正常。

但是，如果在我完成所有这些之后，我重新编译我的插件（对插件代码进行一两个小的更改），我的下一个页面加载将导致 Apache 出现段错误。每个后续请求再次正常工作。因此，只有在编译后立即加载第一页才会导致段错误。

几天来我一直在尝试解决这个问题（我不擅长 C 调试），今天，我在我的 apache 错误日志中注意到了这一点：

有人知道发生了什么吗？这是否意味着这不是我的代码并且我一直在寻找一个幻影错误？我相当有信心每次调用 dlopen() 时都会调用 dlcose()。但是，当我在单进程模式下运行 apache 并开始快速刷新页面时，似乎会发生这种特殊的错误/段错误。

当通过函数打开共享库时dlopen()，有没有办法在主程序中调用函数？

我正在尝试使用 dlopen 函数加载动态库。该库包含一个静态对象，该对象在其构造函数中引发异常。我在 dlopen 调用周围有一个“try-catch(...)”块，但它没有捕获异常，我只看到打印了“Abort”。

我怎样才能捕捉到这个异常？

我正在编写一些使用动态共享库作为插件的代码。

我用于构建共享库的命令行如下所示：

在模块中，我可以调用在主可执行文件中加载的任何其他共享库中的函数。

但是我无法访问（导出）可执行文件本身的函数（我收到undefined symbol错误）。

我的电话dlopen看起来像这样：

谁能告诉我的模块如何回调我的可执行文件，而不必将所有可执行文件的实用程序功能放入另一个共享库中？

任何人都知道是否真的存在一个包装器或移植库来访问 Python 上的 Unix 动态链接器？

我正在阅读 FreeBSD 上 dlopen 和朋友的联机帮助页。我正在开发一个跨平台应用程序，该应用程序将共享库用于可加载插件。我以前从未这样做过，但我认为我对它的工作原理有相当的了解。手册页提到了 dlsym()，这似乎是从共享库中获取函数指针的常用方法，以及 dlfunc()，据说它可以避免编译器抱怨将 void* 转换为函数指针。dlsym() 更常见（可移植性？）是否有原因？我想知道是否应该使用 dlfunc() 来避免编译器问题，或者使用 dlsym()。dlfunc() 是可移植的吗？

我有一些用于测试的 c++ 代码，其中第一行是对 dlopen 的调用，以尝试加载我的共享对象。在点击此行时，我收到以下错误：

我增加了内存（free -m 现在报告说，当我的 exe 加载到 gdb 中时，我有大约 120 MB 的空闲空间），但我仍然收到相同的消息。

任何人对其他可能导致此问题的任何想法以及我可以做些什么来解决它？

我正在尝试执行以下操作

伪代码类似于

谢谢

所以大家可能都知道glibc/lib/libc.so.6可以像普通的可执行文件一样在shell 中执行，在这种情况下它会打印其版本信息并退出。这是通过在 .so 中定义一个入口点来完成的。在某些情况下，将其用于其他项目也可能很有趣。不幸的是，您可以通过 ld 的 -e 选项设置的低级入口点有点太低级：动态加载程序不可用，因此您无法调用任何适当的库函数。出于这个原因，glibc 通过这个入口点中的裸系统调用来实现 write() 系统调用。

我现在的问题是，任何人都可以想出一种好方法，如何从该入口点引导一个完整的动态链接器，以便可以访问其他 .so 的函数？

我最近一直在用 valgrind 调试一些应用程序，我从dlopen.

这看起来像是为 初始化的错误消息dlerror，但是查看手册页，它没有说明如何清除它。知道如何正确摆脱这个吗？