Hinzufügen-Boost macht Debug Build hängen von „non-D“ MSVC Runtime-DLLs

https://stackoverflow.com/questions/222778

03-07-2019
|

Frage

Ich habe ein lästiges Problem, das ich in der Lage sein könnte, irgendwie zu umgehen, aber auf der anderen Seite wäre es viel lieber oben und verstehe, was genau los ist, da es dieses Zeug wirklich aussieht sind hier zu bleiben.

Hier ist die Geschichte: Ich habe einen einfachen OpenGL-App, die gut funktioniert: nie ein großes Problem bei der Erstellung, Verknüpfung, oder es läuft. Jetzt habe ich beschlossen, zu versuchen, einige der intensiveren Berechnungen in einen Arbeitsthread, um zu bewegen, um möglicherweise die GUI noch reaktions zu machen -. Mit Boost.Thread, natürlich

Kurz gesagt, wenn ich das folgende Fragment am Anfang meiner CPP-Datei hinzu:

#include <boost/thread/thread.hpp>

void dummyThreadFun() { while (1); }    

boost::thread p(dummyThreadFun);

, dann beginne ich immer „Die Anwendung konnte nicht gestartet werden, weil msvcp90.dll nicht gefunden wurde“ beim Versuch, das Debug-Build zu starten. (Release-Modus funktioniert ok.)

Jetzt auf der ausführbaren Datei suchen, um den Dependency Walker verwenden, der auch nicht diese DLL nicht findet (was zu erwarten ist glaube ich), konnte ich sehen, dass wir für sie suchen, um die folgenden Funktionen in der Lage sein zu nennen:

?max@?$numeric_limits@K@std@@SAKXZ
?max@?$numeric_limits@_J@std@@SA_JXZ
?min@?$numeric_limits@K@std@@SAKXZ
?min@?$numeric_limits@_J@std@@SA_JXZ

Als nächstes habe ich versucht, jede Instanz min und max umwandeln Makros zu verwenden, anstatt, aber wahrscheinlich nicht alle Verweise auf sie finden konnte, da dies nicht helfen. (Ich verwende einige externen Bibliotheken, für die ich nicht habe, den Quellcode zur Verfügung Aber selbst wenn ich dies tun könnte -.. Ich glaube nicht, es ist der richtige Weg, wirklich)

Also, meine Fragen - ich denke - sind:

Warum suchen wir nach einer nicht-Debug-DLL, obwohl mit dem Debug-Build zu arbeiten?
Was ist der richtige Weg, um das Problem zu beheben? Oder sogar eine schnelle und unsaubere ein?

hatte ich die ersten in einer ziemlich Vanille-Installation von Visual Studio 2008. Dann versucht, das Feature Pack und die Installation von SP1, aber sie hat auch nicht geholfen. Natürlich auch mehrmals neu zu erstellen versucht.

Ich bin mit vorkompilierte Binaries für Boost (v1.36.0). Dies ist nicht das erste Mal, dass ich Erhöhung in diesem Projekt verwenden, aber es kann das erste Mal sein, dass ich einen Teil verwenden, die auf einer separaten Quelle basiert.

Das Deaktivieren inkrementelle Verknüpfung nicht hilft. Die Tatsache, dass das Programm OpenGL scheint nicht relevant zu sein, entweder - ich habe ein ähnliches Problem, wenn die gleichen drei Zeilen Code in ein einfaches Konsolenprogramm hinzugefügt (aber da war es beschwerte sich über msvcr90.dll und _mkdir, und als ich letztere mit boost::create_directory ersetzt, das Problem ging weg !!). Und es ist wirklich nur das Entfernen oder Hinzufügen dieser drei Linien, die das Programm läuft ok machen, oder nicht ausgeführt ist.

Ich kann nicht sagen, ich verstehe, Side-by-Side (weiß nicht, selbst wenn diese in Beziehung steht, aber das ist, was ich jetzt übernehmen), und um ehrlich zu sein, ich bin nicht super-interessiert entweder - sofern ich kann einfach erstellen, debuggen und bereitstellen meine app ...

Bearbeiten 1: Bei dem Versuch, ein abgespeckte Beispiel zu bauen, dass ohnehin das Problem wiedergibt, habe ich entdeckt, dass das Problem mit dem zu tun hat? hier wir hat nun ein Paket mit denen ich war in der Lage, das Problem auf eine fast Vanille Installation von WinXP32 + VS2008 + Erhöhung 1.36.0 (noch vorgefertigte Programme von BoostPro Computing ).

Der Täter ist sicherlich die Spread-lib, mein Build von denen erfordert irgendwie eine ziemlich archaische Version von STLPort für MSVC 6 ! Trotzdem finde ich immer noch die Symptome relativ amüsant. Auch wäre es schön, zu hören, wenn Sie das Problem tatsächlich reproduzieren können - einschließlich Szenarien 1-3 oben. Das Paket ist recht klein, und es sollten alle erforderlichen Teile enthalten.

Wie sich herausstellt, hat das Problem nicht wirklich etwas mit Boost.Thread zu tun haben gesagt, wie dieses Beispiel nun die Boost-Filesystem-Bibliothek verwendet. Darüber hinaus ist es jetzt beschwert sich über msvcr90.dll, nicht P wie zuvor.

Lösung

Boost.Thread hat einige mögliche Kombinationen zu bauen, um für alle Unterschiede zu versuchen und sorgen Szenarien bei der Verknüpfung möglich mit MSVC. Zum einen können Sie entweder Link statisch Boost.Thread, oder einen Link zu Boost.Thread in einem separaten DLL. Sie können dann eine Verknüpfung mit der DLL-Version der MSVC Laufzeit oder der statischen Bibliothek Laufzeit. Schließlich können Sie mit dem Debug-Runtime verknüpfen oder die Freigabe der Laufzeit.

Der Boost.Thread Header versuchen und die automatische Erkennung des Build-Szenarios der vordefinierten Makros, die der Compiler generiert. Um gegen die Version zu verknüpfen, die den Debug-Runtime verwendet müssen Sie _DEBUG definiert haben. Dies geschieht automatisch, definiert durch den / MD und / MDd Compiler-Schalter, so sollte es in Ordnung sein, aber Ihre Beschreibung des Problems schlägt anders.

Wo haben Sie die vorgefertigten Binärdateien aus? Sind Sie explizit eine Bibliothek in den Projekteinstellungen auswählen, oder lässt du die automatische Verbindungsmechanismus die entsprechende LIB-Datei wählen?

Andere Tipps

Ich glaube, ich habe das gleiche Problem mit Boost-in der Vergangenheit hatten. Von meinem Verständnis geschieht es, weil die Boost-Header einen Präprozessor Befehl verwenden, um gegen die richtige lib zu verknüpfen. Wenn Ihre Debug-und Release-Bibliotheken im selben Ordner sind und haben unterschiedliche Namen der „auto-Link“ -Funktion wird nicht richtig funktionieren.

Was ich getan habe ist BOOST_ALL_NO_LIB für mein Projekt definieren (die die Header von „auto linking“ verhindert) und dann die Projekteinstellungen VC verwenden gegen die richtigen Bibliotheken zu verbinden.

Sieht aus wie andere Leute die Boost-Seite des Problems beantwortet haben. Hier ist ein wenig Hintergrundinformationen über die MSVC Seite der Dinge, die weite Kopfschmerzen sparen können.

Es gibt 4 Versionen des C (und C ++) möglich Laufzeitumgebungen:

/ MT: libcmt.lib (C), libcpmt.lib (C ++)
/ MTd: LIBCMTD.LIB libcpmtd.lib
/ MD: msvcrt.lib, MSVCPRT.lib
/ MDd: MSVCRTD.LIB MSVCPRTD.lib

Die DLL-Versionen benötigen noch in diesem statischen lib Verknüpfung (was irgendwie tut all das Setup an die DLL zur Laufzeit zu verknüpfen - ich weiß nicht, die Details). Beachten Sie in allen Fällen Debug-Version hat die d Suffix. Die C-Laufzeit verwendet die c Infix und der C ++ Laufzeit verwendet die cp Infix. Sehen Sie das Muster? In jeder Anwendung, sollten Sie immer nur eine Verknüpfung zu den Bibliotheken in einer dieser Zeilen.

Manchmal (wie in Ihrem Fall), findet man sich mit jemandem verbindet statische Bibliothek anderes, dass die falsche Version der C oder C ++ Runtimes (über das furchtbar ärgerlich #pragma comment(lib)) zu verwenden, konfiguriert ist. Sie können diese Ausführlichkeit indem Sie Ihren Linker erkennen Weg nach oben, aber es ist eine echte PITA für die Jagd. Die „kill einen Nagetier mit einer Bazooka“ Lösung ist, die /nodefaultlib:... Linker Einstellung zu verwenden, um das 6 C und C ++ Bibliotheken, um auszuschließen, dass Sie wissen, dass Sie nicht brauchen. Ich habe dies ohne Problem in der Vergangenheit, aber ich bin nicht sicher, es werde immer arbeiten ... vielleicht wird jemand aus der Versenkung kommt mich zu sagen, wie diese „Lösung“ Ihr Programm verursachen kann am Dienstagnachmittag Baby essen .

Dies ist ein klassischer Link-Fehler. Es sieht aus wie Sie auf eine Boost-Verknüpfung DLL , die sich auf die falsche C ++ Runtime-Links (es gibt auch diese Seite eine Text Suche nach „Threads“). Es sieht auch wie die boost::posix::time Bibliothek Links auf die richtige DLL.

Leider ich finde nicht die Seite, die beschreibt, wie der korrekt gebauten Boost-DLL holen (obwohl ich ein drei Jahre alte E-Mail , die BOOST_THREAD_USE_DLL und BOOST_THREAD_USE_LIB zu zeigen scheint).

auf Ihre Antwort Suche wieder, es scheint, Sie verwenden vorgefertigte Binärdateien. Die DLL Sie nicht in der Lage sind, zu verbinden, ist Teil des TR1 Feature Pack (zweite Frage auf dieser Seite). dieses Feature Pack ist auf der Microsoft-Website verfügbar . Oder werden Sie eine andere binäre müssen verknüpfen gegen. Anscheinend ist die boost::posix::time Bibliothek Links gegen die ungepatchte C ++ Laufzeit.

Da Sie bereits das Feature Pack angewandt wird, denke ich, der nächste Schritt, den ich würde Boost von Hand zu bauen sei. Das ist der Weg, den ich immer gemacht habe, und es ist sehr einfach: herunterladen bjam binären , und führen Sie den Boost-Build-Skript in der Bibliothek Quelle. Das ist es.

Jetzt hätte dies noch ein wenig interessanter ... Wenn ich diese irgendwo in der Quelle nur noch hinzufügen:

boost::posix_time::ptime pt = boost::posix_time::microsec_clock::universal_time();

(zusammen mit den entsprechenden #include Sachen), dann funktioniert es wieder ok. Das ist also eine schnelle und nicht einmal zu schmutzig Lösung, aber hey - was hier vor sich geht, wirklich

Aus dem Gedächtnis verschiedenen Teilen der Boost-Bibliotheken müssen Sie einige Präprozessor Flags definieren, um der Lage sein, richtig zu kompilieren. Sachen wie BOOST_THREAD_USE_DLL und so weiter.

Die BOOST_THREAD_USE_DLL wird nicht das sein, was diesen speziellen Fehler verursacht, aber es kann man _DEBUG oder etwas ähnliches definieren erwarten. Ich erinnere mich vor ein paar Jahren in unserer Boost C ++ Projekte, die wir in der Visual Studio-Compiler-Optionen erklärt recht ein paar zusätzliche BOOST_XYZ Präprozessordefinitionen hatte (oder Make-Datei)

Überprüfen Sie die config.hpp Datei im Boost-Thread-Verzeichnis. Wenn Sie in den ptime Sachen ziehen wird es möglicherweise eine andere config.hpp Datei einschließlich, die dann anders jene Präprozessor Dinge definieren können.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow