Bibliothèque de VC Clashing problème

Question

Je travaille sur un projet C ++ qui utilise Qt (lib IUG), VTK (graphiques lib) et une autre bibliothèque qui est si obscure que je ne citerai pas son nom et sera plutôt l'appeler LIB_X. Le projet utilise Qt pour les composants et interfaces graphiques (VTK plus précisément l'extension QVTKWidget fournie par VTK qui prend en charge Qt) pour rendre la géométrie .. et il utilise LIB_X pour recueillir et manipuler la géométrie.

Le problème est qu'il se avère que LIB_X utilise en fait VTK (où et comment, je ne sais pas, il est la source fermée). Au début, il n'y avait pas de problème, la compilation des deux libs liées allait bien, mais à un moment donné, j'ai appelé un certain (et très nécessaire) fonction LIB_X et en compilant a conduit à un tas de « bla bla quelque chose sur un VTK lib / obj déjà défini des erreurs dll LIB_X.

par exemple. (Et notez c'est avec / FORCE: MULTIPLE il est donc un avertissement ici, laissez-moi savoir si vous voulez l'erreur sans / FORCE: MULTIPLE et je vais le poster):

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);

J'ai essayé d'utiliser / FORCE: MULTIPLE et il semblait être un miracle au début, mais je reçois des erreurs aléatoires dans le code qui la plupart du temps donner des erreurs de tas. J'ai décidé de supprimer toutes les références à LIB_X du projet principal et créé une lib statique qui traiterait tous les trucs de LIB_X. Je ne suis pas un expert C de, donc je ne suis pas certain comment il gère froissement lib lorsque vous utilisez une lib pré-compilé, mais j'ai encore reçu des erreurs discordantes lib en liant mon lib statique dans mon projet principal, donc je reste doivent utiliser / FORCE: MULTIPLE.

Une fois que j'avais la charge statique lib il semblait que les erreurs aléatoires avaient disparu, j'ai pu faire beaucoup avec des méthodes LIB_X dans le projet principal via la lib statique, mais de nulle part, j'ai ajouté une nouvelle donnée membre à ma principale classe de projet (un std :: vectoriel de doubles) et tout à coup je devenais une erreur de tas dans l'une des méthodes de ma bibliothèque statique. Si je commentais le nouveau membre de données, la méthode de la bibliothèque statique irait bien. Je déteste donner l'erreur actuelle, parce que honnêtement, je ne suis pas sûr d'examiner cela vaut la peine, mais ici, il est de toute façon dans le cas où il peut aider:

Note: il se bloque à xutility sur la ligne 151 au sujet, jusqu'à l'affirmation pops: "File: ligne de dbgheap.c: 1279 expression: _CrtIsValidHeapPointer (pUserData)"

L'erreur vient après l'ajout d'un double vecteur de vecteur à un vecteur vecteur vecteur double, écraser sur la ligne de 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

Il n'a commencé à planter ici quand j'ai ajouté un nouveau membre de données à mon projet principal (distincte de la lib statique!) Commentant le nouveau membre de données prend l'erreur loin.

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

, / FORCE: MULTIPLE semble mauvais, je reçois des erreurs aléatoires qui ne font tout simplement pas de sens pour moi. Y at-il d'autres solutions? Suis-je foiré? Y at-il quelque chose que je peux faire avec liaison de LIB_X de VTK?

Answer 1

Je rencontrais un tas d'erreurs de LNK4006 en liant mon application à une bibliothèque (appeler LIB_Y bibliothèque) qui a fait un usage intensif de std::vector<std::string>, que je l'ai fait aussi dans mon application. Après un peu d'expérimentation, j'ai trouvé une solution qui a fonctionné -. LIB_Y envelopper dans une DLL distincte qui appelle LIB_Y (LIB_Y_WRAPPER, par exemple), puis relier l'application principale contre LIB_Y_WRAPPER

Pour essayer ma suggestion que vous devrez:

1. Changez votre « lib statique qui gère toutes les choses LIB_X » d'un projet LIB statique dans un projet DLL (que j'appellerai LIB_X_WRAPPER).
2. Assurez-vous que les fichiers d'en-tête de LIB_X_WRAPPER ne comprennent pas les fichiers d'en-tête de LIB_X. Ceci est vraiment important parce que l'emballage doit isoler complètement votre application à partir des types de données déclarées dans les fichiers d'en-tête de LIB_X (comme std::vector<double>). Seulement consulter les fichiers d'en-tête de LIB_X à partir dans les fichiers source de LIB_X_WRAPPER.
3. Modifier la déclaration de toutes les classes et fonctions dans votre lib statique pour garantir l'exportation de la DLL (voir cette réponse si vous avez besoin de détails sur l'exportation à partir d'une DLL).

Cette solution a fonctionné pour moi, car il a gardé l'instanciation (fonctions générées par le compilateur) de la classe std::vector<std::string> utilisée par Liby complètement séparé de l'instanciation de std::vector<std::string> dans mon application.

En aparté, je soupçonne que la cause de l'accident que vous voyez (vous en commentaire est dans le destructor de std::vector<double>) est parce que l'instanciation de std::vector<double> dans votre application est différente de celle dans LIB_X.

Answer 2

Le commentant est probablement juste au hasard chance -. Si vous corrompent le tas que vous ne voyez pas toujours tout de suite, mais un vecteur stl affecterez et les choses désaffecter gauche et à droite il est donc pas étonnant que ce soit pour trouver l'erreur

Certains nécessitent libs vous inclure des choses dans un certain ordre. Je ne sais pas pourquoi exactement parce que pour moi, il semble que d'abandonner et de dire que vous ne pouvez pas concevoir une bibliothèque bien, mais c'est la triste réalité. Tant que vous n'incluez pas ce lib_x partout que vous incluez VTK il devrait être très bien, cependant.

Cependant, ils pourraient se battre sur une ressource ou d'utiliser quelque chose de mal qui le rend impossible pour eux de travailler ensemble. Si vous êtes en mesure d'obtenir la compilation de travailler ok en les séparant et il ne fonctionne toujours pas alors oui, vous êtes juste hors de la chance parce qu'il est juste un défaut de la manière que ce lib_x a été conçu et puisqu'il est si obscur il est peu probable d'avoir été à fond contre débogué toutes les utilisations. Quand quelque chose n'est pas largement utilisé, il finit généralement par être quelque chose qui fonctionne sur la machine du développeur et projet, mais pas nécessairement quelqu'un d'autre.