VC ++ Clashing Problema Biblioteca

Question

Estoy trabajando en un proyecto de C ++ que utiliza Qt (GUI lib), VTK (gráficos lib) y la otra biblioteca que es tan oscuro que no voy a mencionar su nombre y en su lugar llamarlo LIB_X. El proyecto utiliza Qt para los componentes de interfaz gráfica de usuario y VTK (más precisamente la extensión QVTKWidget proporcionada por VTK que soporta Qt) para la prestación de geometría .. y utiliza LIB_X para recoger y manipular la geometría.

El problema es que resulta que en realidad utiliza LIB_X VTK (dónde y cómo, no sé, es de código cerrado). Al principio no había ningún problema, compilando con las dos bibliotecas enlazadas que estaba pasando bien, pero en algún momento me llamó un cierto (y muy necesario) la función LIB_X y compilar llevó a un montón de 'bla, bla, algo sobre un lib VTK / ya obj definido en errores LIB_X DLL'.

por ejemplo. (Y tenga en cuenta esto es con / FUERZA múltiple por lo que es una advertencia aquí, que me haga saber si desea que el error sin / FUERZA múltiple y mí 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);

He intentado utilizar / FUERZA múltiple y parecía ser un milagro al principio, pero estoy recibiendo errores aleatorios de código que la mayoría de dar errores montón. Decidí eliminar todas las referencias a LIB_X del proyecto principal y creé un lib estática que se ocuparía de todas las cosas LIB_X. No soy experto en C ++, así que no estoy seguro de cómo se maneja choque lib cuando se está utilizando un lib precompilado, pero todavía recibido errores en pugna lib al vincular mi lib estática en mi proyecto principal, por lo que todavía tener que usar / FUERZA múltiple.

Una vez tuve la estática lib parecía que los errores aleatorios se habían ido, yo era capaz de hacer mucho con métodos LIB_X en el proyecto principal a través de la lib estática, sino de la nada, he añadido un nuevo miembro de datos a la clase de mi proyecto principal (un std :: vector de dobles) y de repente me estaba poniendo un error de pila en uno de los métodos de mi biblioteca estática. Si se lo comenté a cabo el nuevo miembro de datos, el método de la biblioteca estática funcionaría bien. No me gusta dar el error actual, porque sinceramente no estoy seguro de si el examen valdrá la pena, pero aquí está de todos modos en caso de que puede ayudar:

Nota: se bloquea a xutility en acerca de la línea 151, hace estallar para arriba afirmación: "Archivo: Línea dbgheap.c: Expresión 1279: _CrtIsValidHeapPointer (pUserData)"

viene el error después de la adición de un doble vector vector a un doble vector vector vector, rompiendo en la línea push_back:

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

Sólo se comenzó estrellarse aquí cuando he añadido un nuevo miembro de datos a mi proyecto principal (separada de la lib estática!) Al comentar el nuevo miembro de datos toma el error de distancia.

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

Así, / FUERZA múltiple parece mal, me da errores aleatorios que simplemente no tienen sentido para mí. ¿Hay otras soluciones? ¿Estoy jodido? ¿Hay algo que pueda hacer con la vinculación de LIB_X de VTK?

Answer 1

me encontré con un montón de errores LNK4006 al vincular mi aplicación a una biblioteca (llámese LIB_Y biblioteca) que hace un uso intensivo de std::vector<std::string>, el cual también hice en mi aplicación. Después de un poco de experimentación encontré una solución que funcionó -. Envuelva LIB_Y en una DLL independiente que llama LIB_Y (LIB_Y_WRAPPER, por ejemplo), y luego enlazar la aplicación principal en contra de LIB_Y_WRAPPER

Para probar mi sugerencia que necesitará:

1. Cambiar el "lib estática que se encarga de todas las cosas LIB_X" de un proyecto LIB estático en un proyecto DLL (que llamaré LIB_X_WRAPPER).
2. Asegúrese de que los archivos de cabecera de LIB_X_WRAPPER no incluyen ninguno de los archivos de cabecera LIB_X. Este es realmente importante porque el envoltorio tiene que aislar por completo la aplicación de los tipos de datos declarados en los archivos de cabecera LIB_X (como std::vector<double>). Sólo se refieren a los archivos de cabecera de LIB_X desde el interior de los archivos de origen de LIB_X_WRAPPER.
3. Cambiar la declaración de todas las clases y funciones en su lib estática para asegurar que se exportan desde la DLL (ver esta respuesta si necesita información sobre cómo exportar desde un archivo DLL).

Esta solución funcionó para mí, ya que mantiene la creación de instancias (compilador genera funciones) de la clase std::vector<std::string> utilizado por LIBY completamente separada de la creación de instancias de std::vector<std::string> en mi aplicación.

Como acotación al margen, sospecho que la causa del accidente que está viendo (que comentas es en el destructor de std::vector<double>) es debido a que la creación de instancias de std::vector<double> en su aplicación es diferente a la de LIB_X.

Answer 2

El comentando es, probablemente, la suerte simplemente al azar. - si está corrompiendo el montón que no siempre se ve de inmediato, pero un vector de STL asignar y cosas desasignar la izquierda y la derecha por lo que no es de extrañar se trata de encontrar el error

Algunas bibliotecas requieren incluir cosas en un orden determinado. No estoy seguro de por qué exactamente, porque a mí me parece que renunciar y decir no se puede diseñar una biblioteca adecuada, pero es la triste realidad. Siempre y cuando no se incluye este lib_x en cualquier lugar de incluir vtk que debería estar bien, sin embargo.

Sin embargo, podrían estar luchando por algún recurso o el uso de algo indebidamente que hace que sea imposible para que trabajen juntos. Si usted es capaz de obtener la compilación para trabajar bien mediante la segregación de ellos y sigue fallando entonces sí que está justo fuera de suerte, porque es sólo un defecto en la forma en que esta lib_x fue diseñado y puesto que es tan oscuro que no es probable que haya sido depurado a fondo contra todos los usos. Cuando algo no se usa ampliamente por lo general termina siendo algo que funciona en la máquina y el proyecto del desarrollador, pero no necesariamente de ninguna otra persona.