Ich kenne .o sind Objektdateien, .a sind statische Bibliotheken und .so sind dynamische Bibliotheken? Was ist ihre körperliche Bedeutung? Wann kann ich welche verwenden und wann nicht?Was ist der Unterschied zwischen .o .a und .so Dateien?
.so sind freigegebene Bibliotheksdateien. .a sind statische Bibliotheksdateien.
Sie können statisch auf .a-Bibliotheken verlinken und zur Laufzeit .so-Dateien dynamisch verknüpfen und laden, vorausgesetzt, Sie kompilieren und verknüpfen auf diese Weise.
.o sind Objektdateien (sie erhalten von * .c Dateien kompiliert und verknüpft werden können ausführbare Dateien, .a oder .so Bibliotheken erstellen. Lesen Sie mehr darüber here
Gibt es nicht auch eine Möglichkeit, Bibliotheken zur Laufzeit zu laden? – Pacerier
.a ein „Archiv“ ist. Obwohl ein Archiv kann jede Art von Datei enthalten, im Kontext der GNU-Toolchain ist es eine Bibliothek von Objektdateien (andere Toolchains, speziell auf Windows verwenden .lib für den gleichen Zweck, aber das Format von diesen ist normalerweise kein allgemeines Archiv, (und oft spezifisch für die Toolchain) Es ist möglich, einzelne Objektdateien aus einem Archiv zu extrahieren, was im Wesentlichen der Linker tut, wenn er die Bibliothek verwendet
.o ist eine Objektdatei. Dies ist Code, der zu Maschinencode kompiliert wird, aber (normalerweise) nicht vollständig verknüpft ist - er kann nicht aufgelöste Verweise auf Symbole haben, die in anderen Objektdateien (in einer Bibliothek oder einzeln) definiert sind und durch separate Kompilierung erzeugt werden. Objektdateien enthalten Metadaten zur Unterstützung der Verknüpfung mit anderen Modulen und optional auch zum symbolischen Debugging auf Source-Ebene (z. B. in GDB). Andere Toolchains, wiederum typischerweise unter Windows, verwenden die Erweiterung .obj statt .o.
.so ist eine gemeinsame Objektbibliothek (oder nur gemeinsam genutzte Bibliothek). Dies ist dynamisch mit einer ausführbaren Datei verknüpft, wenn ein Programm gestartet wird und nicht statisch zum Zeitpunkt der Erstellung verknüpft ist. Es ermöglicht kleinere ausführbare Dateien und eine einzelne Objektbibliotheksinstanz, die von mehreren ausführbaren Dateien verwendet werden kann. Betriebssystem-APIs sind in der Regel gemeinsam genutzte Bibliotheken, und sie werden oft auch in GNU aus Lizenzgründen verwendet, um LGPL-Code von geschlossenem Quellcode zu trennen (ich bin kein Anwalt - ich mache keine Ansprüche bezüglich der Legitimität dieses Ansatzes in jede besondere Situation). Im Gegensatz zu .o oder .a Dateien müssen .so Dateien, die von einer Anwendung verwendet werden, auf dem Laufzeitsystem verfügbar sein. Andere Systeme (wieder typischerweise Windows) verwenden .dll (Dynamic Link Library) für den gleichen Zweck.
Es ist vielleicht nützlich zu verstehen, dass .o Dateien vor Objektcode in .a Dateien so verbunden sind, dass, wenn ein Symbol Auflösung durch eine .o Datei erfüllt ist, wird jede Bibliothek Implementierung nicht verknüpft werden - so dass Sie im Wesentlichen Bibliothek ersetzen Implementierungen mit eigenen und auch für Bibliotheksimplementierungen zum Aufrufen von benutzerdefiniertem Code - zum Beispiel kann ein GUI-Framework einen Anwendungseingangspunkt aufrufen.
In Bezug auf "* .o Dateien sind vor Objektcode in .a * verknüpft", meinst du, dass tritt unabhängig von der Reihenfolge auf, die Sie angegeben haben? – Pacerier
Statische Bibliotheken sind Archive, die den Objektcode für die Bibliothek enthalten, wenn sie in eine Anwendung eingebunden sind, die in die ausführbare Datei kompiliert wurde.
Gemeinsame Bibliotheken unterscheiden sich darin, dass sie nicht in die ausführbare Datei kompiliert werden. Stattdessen durchsucht der dynamische Linker einige Verzeichnisse nach den benötigten Bibliotheken und lädt diese dann in den Speicher. Mehr als eine ausführbare Datei kann dieselbe gemeinsame Bibliothek zur gleichen Zeit verwenden, wodurch die Speicherauslastung und die ausführbare Dateigröße reduziert werden. Es sind dann jedoch mehr Dateien mit der ausführbaren Datei zu verteilen. Sie müssen sicherstellen, dass die Bibliothek auf dem System des Benutzers installiert ist, wo der Linker sie finden kann. Die statische Verknüpfung beseitigt dieses Problem, führt jedoch zu einer größeren ausführbaren Datei.
'Allerdings gibt es dann mehr Dateien mit der ausführbaren Datei zu verteilen. Im Idealfall ist das genaue Gegenteil der Fall. Binärpakete auf z.B. Linux kann natürlich nicht herumlaufen und versuchen, Duplikate von allgemeinen Bibliotheken immer wieder zu installieren. Sie markieren eine Abhängigkeit und verpflichten den Benutzer, sie zu installieren. Selbst wenn man mit einem Paketmanager austeilt, kann man oft annehmen, dass entweder das System des Benutzers bereits benötigte Bibliotheken hat oder der Benutzer sie erwerben kann. Es ist meistens Windows, das die Dinge oft so schwierig macht, dass wir alle DLLs aufgeben und verteilen. Was, äh ..., besiegt irgendwie den Punkt der dynamischen Verknüpfung –
Warum ist dies mit Java getaggt? – JonK