views:

64

answers:

1

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?

+1  A: 

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:

#include <bubbles/thread.hpp>
#include <boost/thread.hpp>

bubbles::thread* thread_1;
boost::thread* thread_2;

I imagine some of the guys here already faced a similar situation. There are probably better alternatives to the one I suggested above.

karlphillip