Auswirkungen unterschiedlicher CRT-Konfigurationen
-
Eine meiner verwendeten Bibliotheken (SFML) scheint eine externe Bibliothek (freetype) zu linken, die mit einer anderen CRT-Konfiguration kompiliert wurde. Deswegen erhalte ich beim Linken von Modulen, welche auf diese externe Bibliothek zugreifen, dauernd die Warnung
warning LNK4098: Standardbibliothek "LIBCMT" steht in Konflikt mit anderen Bibliotheken; /NODEFAULTLIB:Bibliothek verwenden.
Nun, was sind die Konsequenzen dieser Inkompatibilität? Soviel ich weiss, werden gewisse Dinge zur Laufzeit (z.B. Heaps) getrennt verwaltet, wodurch diese nicht über Bibliotheksgrenzen hinweg funktionieren. Und
/NODEFAULTLIBlöst ja das Problem nicht wirklich.Deshalb meine Fragen:
- Wie tragisch ist das tatsächlich? Worauf muss man achten? Ich verwende die externe Bibliothek nicht direkt. Ich wundere mich, was in der Praxis passieren kann, da ich bisher nie Probleme hatte.
- Besteht der einzige saubere Ausweg für die SFML-Entwickler darin, die externen Bibliotheken in allen möglichen Konfigurationen zu kompilieren und jeweils zu linken?
-
Wenn es sich um eine statische LIB handelt, muss diese in der selben Konfiguration undmit dem selben Compiler entwickelt werden, wie auch die EXE die man bauen will.
Glieches gilt für DLLs die nicht nur PODs tauschen.D.h. man muss auf alle Kombinationen CRT statisch/DLL, Debug/Release, passende Versionen liefern. Das macht so schon 4.
-
Vielen Dank für die Antwort.
Dass dann 4 Konfigurationen der externen Bibliothek zur Verfügung stehen müssen, habe ich befürchtet... Falls ich das den Entwicklern vorschlage, müssen diese auch nachvollziehen können, warum die eine bisherige nicht ausreicht. Gerade weil sie eigentlich immer problemlos läuft.
Was könnte also konkret passieren, oder wieso ist die Vermischung unterschiedlicher Konfigurationen grundsätzlich schlecht?
Sorry, falls du das in diesem Forum schon etliche Male erklärt hast. Ich habe meist jedoch nur die Aussage gefunden, dass man das nicht tun soll, und nicht konkret weshalb oder welche Probleme man dabei in Kauf nimmt.
-
Die CRT passt einfach nicht. Punkt. Debug/Release lassen sich gar nicht gegenseitig vermischen. Da fehlen Einsrpungpunkte.
Werden statiche Version und DLL Version gemischt, werden evtl. überflüssige Funktionen in die DLL/EXE gelinkt dir eogentlich in der CRT-DLL drin sind.Einfach mal nachdenken, was es bedeutet! Wird die CRT als DLL Version gelinkt ist das ja nur eine Import-Lib...
Es geht nicht punkt!
-
Wie handhabt man konsistente Laufzeitbibliotheken bei vorgegebenen Bibliotheken wie OpenGL32.dll? Dependency Walker sagt, diese DLL lade MSVCRT.dll. Sobald man also OpenGL mitlinkt, ist man entweder an eine Konfiguration gebunden, oder mischt mehrere.
Oder geht das hier problemlos, weil es sich um eine reine C-Bibliothek handelt und man nur primitive POD-Typen über DLL-Grenzen hinweg bewegt? Also keine CRT-spezifischen Dinge wie File Handles oder Speicherverwaltung?
-
Wäre gut, wenn jemand dazu Stellung nehmen könnte. Immer die richtige CRT-Konfiguration zu linken geht nämlich offenbar nicht.
Ich habe zwar bereits ein paar recht gute Artikel dazu gefunden (einer auf MSDN), doch ganz klar ist mir die Thematik noch nicht. Ist man bei reinen C-Bibliotheken, deren Grenzen nur PODs ohne Bezug zu runtime-spezifischen Funktionen (wie Speicherverwaltung) passieren, auf der sicheren Seite?
-
Das Beispiel ist schlecht... schau Dir mal die mscvrt*.dll an... die linken alle gegen die msvcrt.dll
Fazit bleibt: Du musst in allen *LIBs* darauf achten, dass Du die gleiche CRT verwendest.
Das Thema mit den DLLs ist ein allgemeines und hat nichts mit diesem hier zu tun... wurde aber hier auch schon öfters diskutiert... sollte man einen Blog darüber schreiben...
-
Jochen Kalmbach schrieb:
Fazit bleibt: Du musst in allen *LIBs* darauf achten, dass Du die gleiche CRT verwendest.
Vielen Dank! Das fehlte mir bisher. Also wäre es bei freetype.lib auch sinnvoll, mehrere Konfigurationen zu haben.
Übrigens fand ich im Bezug auf CRT-Kompatibilität diesen Artikel noch nützlich, der hat auch einiges geklärt.
Jochen Kalmbach schrieb:
Das Thema mit den DLLs ist ein allgemeines und hat nichts mit diesem hier zu tun... wurde aber hier auch schon öfters diskutiert... sollte man einen Blog darüber schreiben...
Meinst du ABIs und die Unmöglichkeit, compilerunabhängige C++-DLLs zu erstellen? Darauf zielte ich eigentlich nicht ab. Ich dachte, auch bei C-DLLs könne es je nach CRT Probleme geben. Aber wahrscheinlich bringe ich da was durcheinander.
-
Nexus schrieb:
Ich dachte, auch bei C-DLLs könne es je nach CRT Probleme geben. Aber wahrscheinlich bringe ich da was durcheinander.
Nein! Das geht ohne weiteres.
Ich benutze solche "unabhängigen" DLLs zu Hauf.
Wenn man darauf achtet das die Schnittstellen sauber definiert sind und Allokationen nur innerhalb der DLL gekapselt erfolgen, kann man soche Designs auch super mit C++ Interfaces realisieren.Siehe COM. Dort passiert ja auch nichts anderes.
-
Okay, dann muss ich mir um OpenGL ja keine Sorgen machen.
Vielen Dank an alle für die Beteiligung!
