Ich versuche, dieses Geschäft mit LIB-Dateien unter Microsoft Windows zu verstehen, und ich habe gerade eine Entdeckung gemacht, die – so hoffe ich – die Verwirrung zerstreuen wird, die mich bisher daran gehindert hat, das Problem klar zu verstehen. LIB-Dateien sind nämlich nicht die eine Art von Datei, die ihre Dateierweiterung vermuten lässt.
:: cd "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Lib"
:: lib /nologo /list Ad1.Lib
obj\i386\activdbgid.obj
obj\i386\activscpid.obj
obj\i386\ad1exid.obj
obj\i386\dbgpropid.obj
obj\i386\dispexid.obj
:: lib /nologo /list oledb.lib
o:\winmain.obj.x86fre\enduser\…\oledb\uuid\objfre\i386\oledbiid.obj
o:\winmain.obj.x86fre\enduser\…\oledb\uuid\objfre\i386\oledbnewiid.obj
o:\winmain.obj.x86fre\enduser\…\oledb\uuid\objfre\i386\cmdtreeiid.obj
o:\winmain.obj.x86fre\enduser\…\oledb\uuid\objfre\i386\oledbdepiid.obj
:: lib /nologo /list AdvAPI32.Lib | sort | uniq -c
731 ADVAPI32.dll
Die ersten beiden Beispiele enthalten Objektdateien (die als relative oder absolute Pfade erscheinen, wenn sie von der lib.exe
Dienstprogramm). Das dritte Beispiel enthält jedoch nur 731 Verweise auf eine DLL. (Ich vermute lib.exe
ist nicht darauf ausgelegt, nützlichere Informationen für diese Art von Datei anzuzeigen.)
Einige enthalten Objektdateien und sind statische Bibliotheken. Andere enthalten Symbole und sind Importbibliotheken. (Hier gibt es eine kurze Erklärung.)
Statische Bibliotheken scheinen also die Äquivalente von zu sein .a
Dateien unter Linux und DLLs scheinen zugeordnet zu sein .so
Dateien unter Linux. (Übrigens, wie würden Importbibliotheken in dieses Äquivalenzbild von Windows/Linux passen?)
Jetzt frage ich mich warum das so ist? Warum hat Microsoft entschieden, Importbibliotheken dieselbe Dateierweiterung wie statische Bibliotheken zu geben? (Ich verstehe, dass historisch gesehen zuerst statische Bibliotheken waren, so wie primitive Lebensformen komplexeren Formen vorausgingen.) Warum sagen sie nicht, okay, hier sind diese neuen Arten von Bibliotheken, sie sollen als Importbibliotheken bezeichnet werden, und das sollen sie auch tragen die Dateiendung .ILB
(oder Wasauchimmer)?
Von dem CMake-FAQ: “In Windows gibt es zwei Arten von Bibliotheken, eine statische Bibliothek und eine Importbibliothek (beide verwenden jedoch verwirrenderweise die Erweiterung .lib).” Ich war also nicht der Einzige, der darüber verwirrt war.
– Lumi
2. Juli 2011 um 18:50 Uhr
Übrigens, MinGW/GCC unterstützt das direkte Verlinken mit der DLL: „Die cygwin/mingw-Ports von ld unterstützen das direkte Verlinken, einschließlich Datensymbolen, zu einer DLL ohne die Verwendung von Importbibliotheken. Dies ist viel schneller und verbraucht viel weniger Speicher als die herkömmliche Methode zum Importieren von Bibliotheken, insbesondere beim Verlinken großer Bibliotheken oder Anwendungen … Das direkte Verknüpfen mit einer DLL verwendet keine zusätzlichen Befehlszeilenoptionen außer
-L' and
-l’ … man könnte sich zu Recht fragen, warum überhaupt Importbibliotheken verwendet werden. Dafür gibt es drei Gründe: …”– Lumi
2. Juli 2011 um 19:00 Uhr
Soweit ich verstanden habe, ist es unter Windows nicht wie unter Linux. Du stets Link zu einer .lib. Diese .lib kann entweder den Bibliothekscode enthalten, oder ein Stub, der die DLL lädt und von dort aus ausführt. Sie verknüpfen also gewissermaßen immer statisch eine .lib. Es ist nur so, dass beim dynamischen Linken die .lib nur den Stub enthält und der eigentliche Code in der DLL gespeichert ist.
– Stefan Borini
26. Januar 2015 um 10:21 Uhr
@Lumi Ich bin auch neugierig, was der Vorteil von Import Libraries ist, weißt du nicht? PS: Wo kann das lib-Dienstprogramm, das Sie verwendet haben, bezogen werden? Vielen Dank.
– Wakan Tanka
8. September 2016 um 23:07 Uhr
@WakanTanka,
LIB.EXE
ist Teil von Visual Studio. Was den Vorteil von Importbibliotheken betrifft, nun, sie implementieren dynamische Verknüpfungen, also erledigen sie die Arbeit. 🙂 Der obige Kommentar von Stefano Borini erklärt kurz und bündig, wie sie funktionieren.– Lumi
18. September 2016 um 20:11 Uhr