VC ++ Bibliothek Clashing Problem

Question

Ich arbeite an einem C ++ Projekt, das Qt verwendet (gui lib), VTK (Grafik lib) und eine andere Bibliothek, die so dunkel ist werde ich nicht seinen Namen nennen und es wird stattdessen LIB_X nennen. Das Projekt nutzt Qt für die GUI-Komponenten und VTK (genauer: die QVTKWidget Erweiterung von VTK vorausgesetzt, dass Stützen Qt) für die Darstellung von Geometrie .. und es verwendet LIB_X Geometrie zu sammeln und zu bearbeiten.

Das Problem ist, dass es stellt sich heraus, dass LIB_X VTK tatsächlich verwendet (wo und wie, weiß ich nicht, es ist Closed-Source). Zuerst war es kein Problem, mit beide libs Kompilieren verknüpft war in Ordnung gehen, aber irgendwann rief ich eine bestimmte (und sehr erforderlich) LIB_X Funktion und Zusammenstellen zu einer Reihe von ‚bla bla etwas führte zu einem VTK lib / obj bereits definiert in LIB_X dLL‘Fehler.

z. (Und Hinweis: Dies ist mit / FORCE: MULTIPLE so ist es eine Warnung ist hier, lassen Sie mich wissen, wenn Sie den Fehler ohne / FORCE wollen: MEHRERE und ich werde es schreiben):

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

Ich habe versucht, mit / FORCE: MULTIPLE und es schien ein Wunder auf dem ersten zu sein, aber ich bin immer zufällige Fehler im Code, die meist Haufen Fehler geben würden. Ich beschloss, alle Verweise auf LIB_X aus dem Hauptprojekt zu entfernen und erstellt eine statische lib, die alle LIB_X Sachen umgehen würde. Ich bin kein C ++ Experten, so dass ich nicht sicher bin, wie es lib Klirren Griffe, wenn Sie eine vorkompilierte lib verwenden, aber ich erhielt noch lib Fehler clashing wenn meine statische lib in mein Hauptprojekt verknüpfen, so dass ich immer noch müssen Gebrauch / FORCE: MULTIPLE.

Nachdem ich die statische hatte lib es wie die zufälligen Fehler schien hatte verschwunden, konnte ich viel mit LIB_X Methoden in dem Hauptprojekt über die statische lib tun, aber wie aus dem Nichts, habe ich ein neues Datenelement mein Hauptprojekt der Klasse (a std :: vector von Doppelzimmer) und plötzlich in einer meiner statischen Bibliothek Methoden ich einen Haufen Fehler. Wenn ich das neue Datenelement kommentiert, wäre die statische Bibliothek Methode gut laufen. Ich hasse den aktuellen Fehler zu geben, denn ehrlich gesagt bin ich nicht sicher, ob die Prüfung es sich lohnen wird, aber hier ist es sowieso im Fall kann es helfen:

Hinweis: es xutility stürzt auf über Linie 151, erscheint Behauptung: "File: Dbgheap.c Zeile: 1279 Ausdruck: _CrtIsValidHeapPointer (pUserData)"

Der Fehler kommt nach Doppel eines Vektor-Vektor-Doppel auf einen Vektor Vektor Vektor Hinzufügen Absturz auf der push_back Zeile:

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

Es begann hier nur abstürzt, wenn ich ein neues Datenelement zu meinem Hauptprojekt hinzugefügt (getrennt von der statischen lib!) Aus einem Kommentar das neue Datenelement den Fehler wegnimmt.

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

So / FORCE: MULTIPLE schlecht scheint, erhalte ich zufällige Fehler, die nicht nur Sinn für mich. Gibt es andere Lösungen? Bin ich geschraubt? Gibt es etwas, das ich mit LIB_X der Verknüpfung von VTK tun?

Answer 1

stieß ich auf eine Reihe von LNK4006 Fehler, wenn meine app zu einer Bibliothek verknüpfen (nennen wir es Bibliothek LIB_Y), die starke Nutzung von std::vector<std::string> gemacht, die ich auch in meiner app tat. Nach ein wenig Experimentieren fand ich eine Lösung, die funktioniert - Wrap LIB_Y in einem separaten DLL, die LIB_Y (LIB_Y_WRAPPER, sagen wir) nennt, und verknüpfen Sie dann die Haupt-App gegen LIB_Y_WRAPPER

.

Mein Vorschlag an versuchen, müssen Sie:

1. Ändern Sie Ihre "statische lib, dass alle Griffe LIB_X stuff" von einem statischen LIB-Projekt in eine DLL-Projekt (was ich will LIB_X_WRAPPER nennen).
2. die Header-Dateien von LIB_X_WRAPPER Stellen Sie sicher, beinhalten keine der LIB_X Header-Dateien. Dies ist wirklich wichtig , weil die Wrapper Bedürfnisse vollständig Ihre App von den Datentypen isolieren in den LIB_X Header-Dateien (wie std::vector<double>) erklärt. Nur beziehen LIB_X die Header-Dateien aus den Quelldateien von LIB_X_WRAPPER.
3. Ändern Sie die Deklaration aller Klassen und Funktionen in Ihrer statischen lib zu gewährleisten, dass sie aus der DLL exportiert werden (siehe diese Antwort wenn Sie Details über von einem DLL Export).

Diese Lösung funktionierte für mich, weil es die Instanziierung (Compiler erzeugte Funktionen) der std::vector<std::string> Klasse, die von LIBY vollständig getrennt von der Instanziierung std::vector<std::string> in meiner app gehalten.

Als Nebenwirkung ich die Ursache des Absturzes vermuten Sie sehen (Sie kommentieren es im Destruktor von std::vector<double> ist), weil die Instanziierung std::vector<double> in Ihrer App ist anders als in LIB_X.

Answer 2

Die Kommentierung out ist wahrscheinlich nur zufällig Glück - wenn Sie den Haufen korrumpieren Sie es nicht immer sofort sehen, aber ein stl Vektor wird zuteilen und ausplanen Dinge links und rechts so ist es kein Wunder, dass es der Fehler ist zu finden.

Einige Libs benötigen Sie die Dinge in einer bestimmten Reihenfolge enthalten. Ich bin nicht sicher, warum genau, weil es mir scheint, wie zu geben und sagen Sie nicht eine Bibliothek richtig gestalten können, aber es ist die traurige Tatsache. Solange Sie diese lib_x überall beinhalten nicht, dass Sie umfassen VTK es sollte in Ordnung sein, aber.

Sie könnten jedoch einige Ressourcen über oder unter Verwendung von etwas falsch, dass Marken kämpfen es unmöglich für sie, zusammen zu arbeiten. Wenn Sie sind in der Lage, die Kompilierung zu arbeiten ok zu erhalten, indem sie Absonderungs und es immer noch nicht, dann ja sind Sie gerade aus Glück, denn es ist nur ein in der Art und Weise versagt, dass diese lib_x entworfen wurde und da es so verdunkeln ist es nicht wahrscheinlich gewesen sein gründlich gegen alle Verwendungen debuggt. Wann ist etwas, das nicht weit verbreitet in der Regel es endet als etwas, das funktioniert auf der Maschine des Entwickler und Projekt aber nicht unbedingt jemand anderen.