在 C++ 中可以使用多个 Boost.Thread 实例应用?
我有一个具有插件架构的应用程序,该应用程序使用 Boost.Threads 作为 DLL(特别是 Mac OS X 框架)。我正在尝试编写一个也使用 Boost.Threads 的插件,并且希望静态链接到库中。一切都构建得很好,但应用程序在我的插件中快速崩溃,位于 Boost.Threads 代码的深处。链接到 Boost.Threads 的 DLL 版本似乎可以解决该问题,但我希望我的插件是独立的。
是否可以通过这样的设置拥有两个 Boost.Threads 实例(一个作为 DLL,一个静态链接在另一个 DLL 中)?如果是这样,我可能会缺少什么来让这两个实例和谐相处?
I have an application with a plug-in architecture that is using Boost.Threads as a DLL (specifically, a Mac OS X framework). I am trying to write a plug-in that uses Boost.Threads as well, and would like to link in the library statically. Everything builds fine but the application quickly crashes in my plug-in, deep within the Boost.Threads code. Linking to the DLL version of Boost.Threads seems to resolve the problem, but I'd like my plug-in to be self-contained.
Is it possible to have two instances of Boost.Threads with such a setup (one as a DLL, one statically linked in another DLL)? If so, what might I be missing to make the two instances get along?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我的团队曾经遇到过类似的问题。由于我此时不会提及的原因,我们必须开发一个使用 2 个不同版本的 Boost(线程、系统、文件系统)的系统。
我们提出并执行的想法是获取我们需要的两个版本的 Boost 的源代码,然后调整其中一个以更改符号和函数名称,以避免名称冲突。
换句话说,我们将源代码(或其他名称)中对名称 boost 的所有引用替换为 bubbles,并对编译进行了更改,以便构建libbubbles 而不是 libboost。
这个过程给了我们两组库,每组都有自己的二进制文件和头文件。
如果您查看我们应用程序的源代码,您会看到类似的内容:
我想这里的一些人已经遇到了类似的情况。除了我上面建议的方法之外,可能还有更好的选择。
Once my team faced a similar problem. For reasons I will not mention at this time, we had to develop a system that used 2 different versions of Boost (threads, system, filesystem).
The idea we came up with and executed was to grab the source code of both versions of Boost we needed, and then tweak one of them to change the symbols and function names to avoid name clashing.
In other words, we replaced all references to the name boost for bubbles inside the sources (or some other name) and also made changes to the compilation so it would build libbubbles instead of libboost.
This procedure gave us 2 sets of libraries, each with having their own binaries and header files.
If you looked at the source code of our application you would see something like:
I imagine some of the guys here already faced a similar situation. There are probably better alternatives to the one I suggested above.