Dynamische und statische Verknüpfung und Bereitstellung in Visual Studio 2010

8

Ich habe ein nicht verwaltetes C ++ - Projekt in Visual Studio 2010. Es verwendet Boost, Glut und eine andere Bibliothek von einem Hersteller.

Ich habe das Projekt eingerichtet, um eine "dll-indepenenent" ausführbare Datei zu erstellen. Alle Boost-Bibliotheken sind statisch verknüpft und es ist keine DLL in dem Verzeichnis erforderlich, in dem die ausführbare Datei verbleibt.

Das gleiche gilt für den Glut, ich habe die statische glut32.lib anstatt der glut32.dll und wieder kein Problem verbunden.

Ich habe für die Runtime-Bibliotheken die NON-DLL-Version ausgewählt, d. h. Multithread-Debug (für Debug-Konfiguration) und Multithread für Release-Konfiguration.

Nun bietet der Verkäufer, den ich vorher gesprochen habe, zwei Alternativen an: eine Vendor.lib und eine Vendor.dll.

Die Vendor.lib wird in den Linker- & gt; Zusätzliche Abhängigkeiten hinzugefügt, aber zur Laufzeit muss ich immer die Vendor.dll im selben Verzeichnis der ausführbaren Datei ablegen, sonst klagt die Laufzeitumgebung, weil sie den Vendor nicht findet .dll-Bibliothek.

Wie soll ich dieses Problem lösen? Ich möchte vermeiden, in jedes Verzeichnis die .dll-Datei zu legen.

Ich möchte nicht die DLL in das gleiche Verzeichnis der exe und im Allgemeinen, was sind die Richtlinien für die Bereitstellung von nicht verwalteten C ++ - Konsolenanwendungen in Visual Studio?

Ich weiß, dass es viele Fragen und Seiten über dieses Argument gibt, aber keine davon hat mir diesen Punkt klargemacht.

Eine Idee?

    
linello 05.03.2012, 13:39
quelle

2 Antworten

10

Microsoft ist ein bisschen komisch in der Art, wie es damit umgeht: wenn Sie ein .dll erstellen Sie auch eine .lib, die die öffentlichen Symbole in der .lib enthält .dll. Sie müssen eine Verknüpfung mit der .lib herstellen, um die DLL unter zu laden Laufzeit, aber diese .lib ist immer noch keine statische Bibliothek. Wenn Ihr Lieferant bietet eine Version für die statische Verknüpfung, es wird entweder keine .dll, oder zwei .lib (vermutlich in verschiedenen Verzeichnissen oder mit anderen Namen). Nur ein weiteres Beispiel von Microsoft, das ernsthafte Entwicklung mehr macht schwierig als nötig.

    
James Kanze 05.03.2012, 13:52
quelle
7

Die Vendor.lib muss eine statisch kompilierte Bibliothek sein. Wenn Sie dies verknüpfen, benötigen Sie noch Vendor.dll, es klingt wie Vendor.lib ist eigentlich eine Import-Bibliothek und nicht eine statische Bibliothek.

Überprüfen Sie, ob der Anbieter eine andere Vendor.lib (die ein gutes Stück größer sein sollte als Ihre aktuelle .lib) ist, die eine statische Bibliothek ist, und versuchen Sie, darauf zu verlinken. Wenn ja, brauchen Sie die DLL nicht.

    
Fraser 05.03.2012 13:51
quelle