c++ link Unterschied zwischen.a.o- und.lo-Dateien




use shared library linux (3)

Was ist der Unterschied zwischen .a und .lo Dateien in C?


Unterschied zwischen .o, .a, .lo und .so.

Zusammenfassung

  • .o ist normalerweise eine Nicht-PIC-Objektdatei, die vom Compiler (vor der Linker-Stufe) ausgegeben wird. Bei einer Verknüpfung mit einem Exe wird der Code in die ausführbare Datei aufgenommen - wir binden zur Linkzeit.
  • .a ist normalerweise eine Archivbibliothek, die eine oder mehrere .o- Dateien enthält (Nicht-PIC). Wenn Sie mit einem Exe verknüpft sind, werden die einzelnen "* .o" -Dateien im Archiv in die ausführbare Datei eingefügt.
  • .lo ist im Allgemeinen ein "Bibliotheksobjekt", das PIC-Code enthält, unabhängig davon, ob er manuell mit gcc -fPIC oder mit libtool kompiliert wird .
  • .so- Dateien sind "Shared Object" -Dateien. Sie enthält PIC-Objekte.

Hinweis:

  • Wenn Sie statische ausführbare Dateien benötigen, verwenden Sie die Dateien ".o" und ".a".
  • Wenn Sie dynamische ausführbare Dateien zum Binden mit Bibliotheken zur Laufzeit benötigen / möchten, verwenden Sie .lo- und .so- Dateien.

Einführung

Obwohl ich die Antworten oben mag, decken sie nicht das .a / Archiv-Bibliotheksformular ab. Deshalb werde ich mich hier an alle drei wenden und außerdem das Hinzufügen eines .so-Bibliotheksformats. In der Geschichte von stackexchange verwende ich auch mehr Text für den Fall, dass Links beschädigt werden (Beachten Sie, dass ich für diesen keinen Referenzlink benötigte).

Dateityp .o

Beim Kompilieren einer .o- Datei handelt es sich um eine Objektdatei, die den vom Compiler ausgegebenen Objektcode für die Zielplattform enthält. So erstellen Sie eine O- Datei:

gcc -c filename.c     <==== creates filename.o

Beachten Sie, dass in diesem Beispiel kein Positionsunabhängiger Code (PIC) erstellt wurde. Wir betrachten dies als ein Objekt für eine mögliche Aufnahme in eine statische Bibliothek oder ausführbare Datei. Wenn wir also eine ausführbare Datei mit einer .o- Datei verknüpfen, wird der Code in der .o-Datei in die ausführbare Datei eingefügt - er ist zur Erstellungszeit gebunden, nicht zur Laufzeit. Das bedeutet, dass die ausführbare Datei ohne die .o-Datei weitergegeben werden kann. Vorbehalt: Es ist üblich, dass die .o- Datei als Nicht-PIC betrachtet wird. In der Regel werden PIC-Objektdateien mit der Erweiterung .lo benannt .

Dateityp .a

Der Dateityp .a ist eine " Archiv " -Bibliothek. Es enthält eine oder mehrere .o-Dateien und wird normalerweise zum Erstellen statischer ausführbarer Dateien verwendet.

Wir verwenden den Befehl ar , um Archivbibliotheken zu bearbeiten. In einem Beispiel, das (1) eine Archivbibliothek aus .o- Dateien erstellt, listet (2) den Inhalt einer auf.

Erstellen Sie die Bibliothek

$ ls *.o
a.o  b.o  c.o                 <=== the files going in the archive

$ ar q libmyStuff.a *.o       <=== put *.o files in an archive (or new one)
ar: creating libmyStuff.a    

$ ls *.a                      <=== just show the library created
libmyStuff.a

Zeigen Sie den Inhalt einer Archivbibliothek an

$ ar t libmyStuff.a
a.o
b.o
c.o

Dateityp .lo

Die Verwendung von .lo ist eine Konvention, die häufig für positionsunabhängige Objektdateien verwendet wird. Im aktuellen Verzeichnis erstellt der Befehl libtool compile sowohl eine .lo- Datei als auch eine .o- Datei, eine mit PIC-Code und eine ohne PIC-Code. Siehe die Ausgabe unten:

$ libtool compile gcc -c a.c
libtool: compile:  gcc -c a.c  -fPIC -DPIC -o .libs/a.o  <== PIC code
libtool: compile:  gcc -c a.c -o a.o >/dev/null 2>&1     <== Not-PIC code

$ ls a.lo a.o
a.lo  a.o       <=== a.lo contains the PIC code.

Beachten Sie auch, dass das .libs- Unterverzeichnis mit ao erstellt wurde. Diese Datei ist trotz des Namens ein PIC-Code. Libtool hat diese Datei in das aktuelle Verzeichnis verschoben und die Erweiterung in .lo geändert .

Sie können .lo- Dateien immer manuell erstellen, indem Sie beim Kompilieren die PIC-Option (en) für gcc verwenden. Verschieben Sie die resultierenden .o- Dateien in die Erweiterung .lo .

Dateityp .so

Konvention .so impliziert eine "Shared Object" -Bibliotheksdatei. Wir legen PIC-Objektdateien in gemeinsam genutzten Bibliotheken ab. Im Rahmen von .o- und .a- Dateien ist der Code nicht in der kompilierten Datei enthalten, wenn wir eine Verknüpfung mit .so- Dateien herstellen. Das heißt, wir verwenden Laufzeitbindung (wie im Fall .lo ). Es gibt mehr als eine Form der Laufzeitbindung, aber darauf wollen wir hier nicht eingehen.









libraries