Question

I am working on a C++ project that uses Qt (gui lib), VTK (graphics lib) and another library which is so obscure I won’t mention its name and will instead call it LIB_X. The project uses Qt for the gui components and VTK (more precisely the QVTKWidget extension provided by VTK that supports Qt) for rendering geometry.. and it uses LIB_X to gather and manipulate geometry.

The problem is that it turns out that LIB_X actually uses VTK (where and how, I don’t know, it’s closed source). At first there was no problem, compiling with both libs linked was going fine, but at some point I called a certain (and highly needed) LIB_X function and compiling led to a bunch of ‘blah blah something about a VTK lib/obj already defined in LIB_X dll’ errors.

e.g. (and note this is with /FORCE:MULTIPLE so it’s a warning here, let me know if you want the error without /FORCE:MULTIPLE and I’ll post it):

1>LIB_X.lib(LIB_X.dll) : warning LNK4006: "public: __thiscall std::vector<double,class std::allocator<double> >::~vector<double,class std::allocator<double> >(void)" (??1?$vector@NV?$allocator@N@std@@@std@@QAE@XZ) already defined in vtkCommon.lib(vtkInformationDoubleVectorKey.obj);

I tried using /FORCE:MULTIPLE and it seemed to be a miracle at first, but I am getting random errors in code that would mostly give heap errors. I decided to remove all references to LIB_X from the main project and created a static lib that would handle all LIB_X stuff. I’m not a C++ expert, so I’m not certain how it handles lib clashing when you’re using a pre-compiled lib, but I still received lib clashing errors when linking my static lib into my main project, so I still have to use /FORCE:MULTIPLE.

Once I had the static lib it seemed like the random errors had gone away, I was able to do a lot with LIB_X methods in the main project via the static lib, BUT out of nowhere, I added a new data member to my main project’s class (a std::vector of doubles) and suddenly I was getting a heap error in one of my static library’s methods. If I commented out the new data member, the static library’s method would run fine. I hate to give the current error, because honestly I’m not sure if examining it will be worthwhile, but here it is anyway in case it can help:

note: it crashes to xutility on about line 151, pops up assertion:
“file: dbgheap.c line: 1279 expression: _CrtIsValidHeapPointer(pUserData)”

The error comes after adding a vector vector double to a vector vector vector double, crashing on the push_back line:

std::vector<std::vector<double>> tmpVec;
for(srvl_iter = srvl.begin(); srvl_iter != srvl.end(); ++srvl_iter)
{
 tmpVec.push_back((*srvl_iter).getControlPoints());
}
this->_splines.push_back(tmpVec); //CRASH

It only started crashing here when I added a new data member to my main project (separate from the static lib!) Commenting out the new data member takes the error away.

std::vector<std::vector<std::vector<double>>> _geometry; 

So, /FORCE:MULTIPLE seems bad, I get random errors that just don’t make sense to me. Are there other solutions? Am I screwed? Is there something I can do with LIB_X’s linking of VTK?

Answer 1

I encountered a bunch of LNK4006 errors when linking my app to a library (call it library LIB_Y) that made heavy use of std::vector<std::string>, which I also did in my app. After a bit of experimenting I found one solution that worked — wrap LIB_Y in a separate DLL that calls LIB_Y (LIB_Y_WRAPPER, say), and then link the main app against LIB_Y_WRAPPER.

To try out my suggestion you will need to:

1. Change your “static lib that handles all LIB_X stuff” from a static LIB project into a DLL project (which I will call LIB_X_WRAPPER).
2. Make sure the header files of LIB_X_WRAPPER don’t include any of the LIB_X header files. This is really important because the wrapper needs to completely isolate your app from the data types declared in the LIB_X header files (such as std::vector<double>). Only refer to LIB_X’s header files from within the source files of LIB_X_WRAPPER.
3. Change the declaration of all classes and functions in your static lib to ensure they are exported from the DLL (see this answer if you need details about exporting from a DLL).

This solution worked for me because it kept the instantiation (compiler generated functions) of the std::vector<std::string> class used by LIBY completely separate from the instantiation of std::vector<std::string> in my app.

As an aside, I suspect the cause of the crash you are seeing (you comment it is in the destructor of std::vector<double>) is because the instantiation of std::vector<double> in your app is different to that in LIB_X.