Sollte ich statisch oder dynamisch mit der Visual Studio C-Laufzeitumgebung verknüpfen?

Question

Ich habe Argumente auf beiden Seiten darüber gelesen, ob man in Visual Studio-Projekten statisch oder dynamisch mit der C-Laufzeitbibliothek verknüpfen sollte, und ich bin mir immer noch nicht ganz sicher, was ich davon halten soll.

Mein Projekt bezieht einige Bibliotheken von Drittanbietern ein (Python, HDF5, Trilinos und Microsoft MPI), die alle mit der gleichen Laufzeitbibliothek wie meine endgültige ausführbare Datei erstellt werden müssen (sonst können sie nicht miteinander verknüpft werden). Beim statischen Linken wird jede dieser Bibliotheken eine Kopie der C-Laufzeitbibliothek enthalten. Ich habe gelesen, dass dies zu Problemen führen kann, weil die endgültige ausführbare Datei mehrere Kopien der Laufzeitbibliothek enthält, von denen keine miteinander interagieren kann. Aber würde sich der Linker nicht beschweren, wenn dieselben Symbole mehrfach definiert wären?

Ich möchte die "DLL-Hölle" vermeiden, bin aber besorgt über heimtückische Fehler, die durch statisches Einbinden mehrerer Kopien der Laufzeitumgebung entstehen könnten. Lese ich die Dinge falsch?

Außerdem verwende ich Visual Studio 2005, und ich habe gelesen, dass die Service Pack 1-Laufzeitumgebung nicht abwärtskompatibel ist. Bedeutet dies, dass eine Anwendung, die ohne SP1 erstellt wurde, nicht auf einem Computer mit SP1-DLLs ausgeführt werden kann, selbst wenn sie denselben Namen haben (z. B. msvcr80.dll)?

Answer 1

Statisches Linken bläht alle Ihre EXEs und DLLs auf und kann zu Abstürzen führen (z.B. wenn Code in einer DLL free() mit einem Zeiger aufruft, der von malloc() in einer anderen DLL alloziert wurde).

Sie können das Beste aus beiden Welten herausholen, indem Sie dynamisch verlinken und die Laufzeit-DLLs als private Assemblies bereitstellen. Dies bedeutet einfach, dass Sie eine Kopie eines speziell benannten Verzeichnisses, das die Laufzeit-DLLs und ihre Manifeste enthält, neben Ihre ausführbare Datei legen.

Siehe den Abschnitt "Bereitstellen von Visual C++ Bibliotheks-DLLs als private Assemblies" unter http://msdn.microsoft.com/en-us/library/ms235291(VS.80).aspx für Details, aber im Grunde sieht Ihre Anwendung wie folgt aus:

c:\Program Files\My App\MyApp.exe
c:\Program Files\My App\MyLibrary.dll
c:\Program Files\My App\Microsoft.VC80.CRT\Microsoft.VC80.CRT.manifest
c:\Program Files\My App\Microsoft.VC80.CRT\msvcr80.dll

Zu Ihrer letzten Frage: Ja, der Zielcomputer benötigt die korrekten Versionen der Laufzeit-DLLs, um zu funktionieren, aber indem Sie sie als private Baugruppen bereitstellen, können Sie das garantieren.

Ein weiterer Vorteil ist, dass Benutzer, die keine Administratoren sind, Ihre Anwendung installieren können (nicht in den Programmdateien, sondern anderswo) - sie benötigen keine Berechtigung, um Dateien in den WinSxS-Bereich zu schreiben.

Answer 2

Das einzige Mal, dass Sie mehrere Kopien der Runtime erhalten, ist, wenn Sie eine Bibliothek statisch in eine DLL verlinken - jede DLL erhält eine Kopie, ebenso wie die Exe. Wenn sie todo Wenn Sie statische Bibliotheken und keine DLLs verwenden, werden sie alle miteinander verknüpft und alle Ihre Bibliotheken haben die gleiche Laufzeit.

Das ist die Aufgabe des Linkers.

Answer 3

Statische Bibliotheken müssen nicht statisch mit anderen statischen Bibliotheken verknüpft werden. Sie müssen nur alle statischen Bibliotheken in Ihrem Hauptprojekt verlinken. Auf diese Weise wird sich der Compiler nicht über mehrere Symbole beschweren.

Answer 4

... Tun Sie es statisch ... Versuche, DLL Hell zu beheben, haben nicht so gut funktioniert ... fügen Sie einfach zusätzliche 200k zu Ihrer Installation mit der statischen Verknüpfung.