Kompilieren und Linken unter Windows

Hier eine kurze Zusammenfassung des Wichtigsten, was man wissen muss, wenn man mit externen (=fremden) Libs entwickeln will:

Libs

Es gibt statische und dynamische Libs. (Welch Wunder.)

Beispiel: Man hat ein myserver.dll, und dazu gehört dann ein myserver.lib, gegen die man linken muss.

In der .lib-Datei (eine Import-Lib, keine statische Lib) steht Code, der beim Ausführen (!!!) der .exe die eigentliche (dynamische) .dll lädt (Fachjargon: ".exe zieht sich .dll"). Diese Import-Lib wird nur beim Linken benötigt; sie muss (im Gegensatz zur zugehörigen .dll) nicht dem Kunden ausgeliefert werden. Der "dll-ziehende Code" ist schon in die importierende .exe (oder auch eine andere .dll oder sogar eine andere .lib :-) ) hineingelinkt worden. Nur noch die .dll muss mit der .exe ausgeliefert werden!

Das ist verwirrend, vor allem dann, wenn (wie bei APR) irgendwo .lib- und .dll-Dateien verstreut herumliegen. Woher soll man wissen, ob das jetzt eine statische oder eine Import-Lib ist? Eine meist funktionierende Heuristik ist es, sich einfach die Größe der Datei anzuschauen. Import-Libs sind typischerweise < 100 kB groß, echte statische dagegen mehrere MB. Außerdem gibt es im bin-Verzeichnis des Visual Studios noch Hilfsporgramme, mit denen man so etwas testen kann.

Kompilieren

Im Visual Studio öffnet man die "Project Property Pages". Dort spezifiziert man, ganz analog zu Unix, die "Additional Include Directories"

Linken

Auch analog zu Unix spezifiziert man die "Additional Library Directories" und die "Additonal Dependencies". Letzteres sind dann die Namen der .lib-Dateien, nicht die .dll's!

Ausführen

Wenn man gegen statische .lib's gelinkt hat, gibt es - wie bei Unix - gar kein Problem. In der .exe ist sämtlicher Code enthalten, und man kann die .exe jedem Windows-Nutzer schicken, und sie wird auf seiner Maschine laufen.

So lange man noch am Entwickeln ist, ist es pragmatisch, gegen statische .libs zu linken.

Wenn man dagegen gegen eine Import-Lib mylib.lib gelinkt hat, kann es passieren, dass beim Ausführen des Programms ein Fenster mit der Meldung "Cannot find mylib.dll" erscheint: Die .exe weiß nicht, wo die mylib.dll zu finden ist und es ist nicht so, dass in dem Verzeichnis gesucht wird, in dem sich beim Linken die mylib.lib befand. (Die .exe kann ja auf einem völlig anderen Rechner an einem völlig anderen Ort im Dateisystem zum Einsatz kommen.)

Zwar gibt es einige Standard-Verzeichnisse, in denen nach dll's gesucht wird (unterhalb von C:\WINDOWS z.B.), aber an diesen Verzeichnissen sollte man möglichst nichts verändern.

Es gibt nun 2 Möglichkeiten:

Neue Projekte in Visual Studio anlegen

Bei unserem Code haben wir schon viele .cpp- und .h-Dateien, die nach dem Auschecken in einem Verzeichnis(-Baum) liegen. Wenn das jetzt unter Windows (mit-, weiter-) entwickelt werden soll, stellt sich die Frage, wie man das entsprechende Projekt einrichtet, so dass alle diese Dateien gefunden werden, man sich aber den Baum nicht durch Studio-eigene Dateien "versaut" (z.B. durch automatisch generierte Makefiles).

Pragmatisch ist folgende Vorgehensweise:

Man öffnet mit File -> New -> Project ein neues Projekt, wählt dort "Win32 Console Application" und spezifiziert als Projektordner irgendeinen neu anzulegenden Ordner irgendwo außerhalb des ausgecheckten Baumes. Als zusätzliche Option wählt man "Empty Project" und deselektiert "Precompiled Headers".

In dem neu entstandenen Projekt fügt man dann mittels "rechte Maustaste auf Projektname im Solution Explorer" -> "Add" -> "Existing Item" seine .cpp's und .h's aus dem ausgecheckten Baum hinzu.

Es wird dabei keine Datei kopiert! Man arbeitet also auf den Original-Dateien.

Alles, was das Studio beim Entwickeln später neu anlegt (Unterordner, .exe's, .obj's, .lib's, Makefiles usw.) wandern in den Projektordner. Der Quellcode-Baum bleibt also sauber.

CompleteSearch: completesearch/CompilingLinkingUnderWindows (last edited 2008-10-31 15:21:00 by mpino1301)