Windows 上带有 Libtool 和 LoadLibrary() 的模块
我正在尝试用 C++ 编写一个跨平台程序,它将在运行时加载某些模块(共享库)。为此,我使用 Poco C++ 库 中的类加载器。我使用 autoconf、automake 和 libtool 编写了一个编译链。这在Linux环境下应该没有问题,但是在Windows下就会出现问题。我在编译时使用 MinGW 和 MSYS 以便能够使用我的 Makefile。 ClassLoader 使用 Windows 特定的 LoadLibrary() 函数来加载模块,这意味着我必须将它们编译为 DLL。
我编译到库的类继承了主应用程序中的另一个类。然后,当我尝试运行 make 时,它会抱怨很多未定义的引用并拒绝构建共享库。我想这是因为名称损坏。或者是因为我无法继承库之外的类? (该类不包含在库的源代码中,但找到了头文件)
我不太确定它会带来多少麻烦,我坚持在 MinGW + MSYS 下编译但仍然使用 LoadLibrary() 。有谁有这方面的经验吗?
I'm trying to write a cross-platform program in c++ that will load certain modules (shared libraries) at runtime. To do this I'm using the ClassLoader from Poco C++ Libraries. I've written a compiling chain using autoconf, automake and libtool. This shouldn't be any problem in a Linux environment, but the problem occurs in Windows. I'm using MinGW and MSYS when compiling to be able to make use of my Makefiles. ClassLoader uses the Windows-specific LoadLibrary() function to load the modules, which means I have to compile them as DLLs.
The class that I compile to a library inherits another class within the main application. Then when I try to run make, it complains a lot about undefined reference and refuses to build a shared library. I guess this is because of the name mangling. Or is it because I can't inherit a class outside of the library? (That class is not included in the sources for the library, but the header file is found)
I'm not really sure how much trouble it's going to bring that I insist on compiling under MinGW + MSYS but still make use of LoadLibrary(). Anyone with experience of this?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
在 Windows 下,DLL 在构建时必须解析其所有符号。在 Unix 下,您可以在加载时之前保留未解决的问题,并且此行为目前已纳入您的设计中。
要改变这一点,您可能必须将主应用程序中的基类(以及 DLL 所依赖的其他所有内容)分解为它自己的 DLL。这样,当您链接子类库时,它可以链接到新的 DLL 并完全解析它的符号。
问题是,您必须能够构建这个新的 DLL,并解析它的所有符号。
Under Windows, a DLL must have all of it's symbols resolved when it's built. Under Unixes, you can leave things unresolved until load-time, and this behavior is currently incorprated into your design.
To change that, you will probably have to break out the base class in the main application (and everything else that the DLL depends on) into it's own DLL. That way, when you link your library that subclasses, it can link to the new DLL and fully resolve it's symbols.
The catch is, you have to be able to build this new DLL with all of it's symbols resolved.