Question

I’m working on a cross-platform Firebreath plugin which is crashing on Windows. I use a static library containing classes which reference boost.asio. When I link this library against the plugin dll, I observe crashes when interacting with the io_service subsystem (ie, during socket construction). When I link the static library against an ordinary executable, the problem does not occur. When I compile the contents of the static library directly into the plugin dll project, the crash does not occur. I have gone to great lengths to ensure that all aspects of my build environment on Windows are consistent (build modes, version of Visual Studio, etc). In addition, I’ve firewalled the boost.asio headers, so that the plugin dll code has no visibility of the boost.asio sub-system (to no effect, unfortunately, vs2008 and vs2010). As far as I can tell, I’ve done everything possible to ensure that the build environment is well behaved but the problem persists.

Can the community offer any advice on potential risks or approaches which could expose or solve the problem?

Answer 1

Two things that are dramatically different between linking a static library vs loading a DLL:

• global initialization: In a DLL, they all run. In a static library, the linker only brings in an object file if it satisfies some unresolved external, so systems which rely on components registering themselves using the constructor or intiialization expression of a global object fail.

• shared CRT: In a static library, all calls to the Standard library are resolved during link time, and the main application and library function all call the same copy of the Standard library. In a DLL, you risk having two copies of the Standard library, which can be ok if you’re careful never to share any Standard library objects (like FILE*, std::string, or even malloc/free pairs) between library and application.

The second thing is most likely what’s biting you. There’s a lazy way to fix it: Use the Standard library DLL, and a better way of fixing it: figure out memory and object lifetime and don’t try to allocate on one side and free on the other, or share C++ class layout across the boundary. Virtual functions work fine across the boundary.

The advantage of the “better” way is that plugins can be built in any version of the compiler, which becomes a big deal for maintenance later on in the development cycle.