将 dll 链接到静态库并将其加载到链接到同一静态库的应用程序中
我正在创建一个应用程序，支持在运行时动态加载的 dll 形式的模块。代码的布局如下：
核心 - 静态库
它有一种加载共享库并调用“创建”函数的机制，该函数返回一个新的模块对象（使用共享标头）。
模块共享库（链接到核心静态库）
该模块使用共享模块头，并且还使用核心库中的其他类（因此它与核心库链接）。它被构建为包含静态库中的所有符号。
测试应用程序可执行文件（与核心静态库链接）
我变得很奇怪，并且看似零星的行为。它们总是以访问冲突告终，但似乎我非常明确设置的成员变量（整数）将在以后的函数中作为垃圾打印出来（我已经验证它们之前没有被删除）。这似乎只有在加载动态库时才会发生（即使我从未调用创建函数）。
我的主要问题是，这里是否存在共享库中的符号与可执行文件中的符号冲突（因为它们来自同一个静态库）并导致问题的危险，即使它们来自完全相同的静态库？
I am creating an application that supports modules in the form of dlls that are loaded dynamically at runtime. The code is laid out in the following way:
core - static library
This has a mechanism to load shared libraries and call a "create" function that returns a new Module object (uses a shared header).
module shared library (linked against core static library)
This module uses the shared Module header and also uses other classes from the core library (hence why it is linked against the core library). It is built to include all symbols from static libraries.
test application executable (linked against core static library)
I am getting funky, and seemingly sporadic behavior. They always end up in access violations but it seems that member variables that I very explicitly set (integers) will print out in later functions as garbage (i have verified that they are not being deleted earlier). This only ever seems to happen if they dynamic library is loaded (even if I never call the create function).
My main question is, is there are danger here that the symbols in the shared library will conflict with the symbols in the executable (since they came from the same static library) and cause problems even though they are from the exact same static library?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我无法代表 Linux 和 OS X 的行为，但在 Windows 上，以下正是正在发生的情况。既然你说你也想在 Windows 上编译，那么这是相关的。
您遇到的问题是核心中的所有内容实际上都有多个版本。每个模块和应用程序本身都有自己的核心副本，并且它们的变量不共享。这包括 C 运行时，因此跨模块边界的 new/delete 之类的事情充满了危险。
要验证这是否正在发生，请创建一个简单的测试：将核心中的全局设置为测试应用程序中的值，然后从从动态加载的代码尝试访问该全局并查看什么你明白了。我敢打赌，你会看到你的商店到全球不会被反映！
解决方案：
1）将core做成共享动态库。这可能是也可能不是您的选择。
2）在了解上述知识的情况下极其谨慎地操作；所有 CRT 和/或您自己的核心状态都不会被共享，因此您必须确保事物将在模块边界的自己一侧分配/销毁，等等。
我自己的应用程序的设计几乎与您的相同；即具有应用程序和模块所需的共享代码的静态库，然后由应用程序核心加载动态加载的插件。
对于必须跨模块访问的所有共享核心状态，我所做的就是每个模块在加载后所做的第一件事是将其“核心指针”设置为应用程序中核心库的实例化。这确保所有模块都使用相同的数据。
I can't speak for Linux and OS X behavior, but on Windows, the following is exactly what is happening. Since you say you also want to compile on Windows, this is relevant.
The problem you are experiencing is that you actually have multiple versions of everything in the core. Each module and the application itself has its own copy of the core, and their variables are not shared. This includes the C runtime, so things like new/delete across module boundaries are fraught with peril.
To verify that this is what is happening, create a simple test: set a global in the core to a value in your test application, then from from your dynamically loaded code try to access that global and see what you get. I will wager that you will see that your store to the global will not be reflected!
Solutions:
1) Make core a shared dynamic library. This may or may not be an option for you.
2) Operate extremely carefully with the knowledge of the above; All CRT and/or your own core state will not be shared, so you must make sure things will be allocated/destroyed on their own side of the module boundaries, among other things.
My own application is designed almost identically to yours; ie a static library with shared code needed by both the application and the modules, and then dynamically loaded plugins loaded by the application core.
What I do for all shared core state that must be accessed across modules is that the first thing each module does after loading is have its "core pointer" set to an instantiation of the core libraries in the application. This ensures that all modules are working with the same data.