it-swarm.com.de

Wie funktionieren SO (Shared Object) -Nummern?

Mir ist bekannt, dass gemeinsam genutzte Objekte unter Linux "so-Nummern" verwenden, dh, dass verschiedene Versionen eines gemeinsam genutzten Objekts unterschiedliche Erweiterungen erhalten, zum Beispiel:

  • example.so.1
  • example.so.2

Ich verstehe, dass die Idee darin besteht, zwei unterschiedliche Dateien zu haben, so dass zwei Versionen einer Bibliothek auf einem System existieren können (im Gegensatz zu "DLL Hell" unter Windows). Ich würde gerne wissen, wie das in der Praxis funktioniert? Oft sehe ich, dass example.so ist in der Tat eine symbolische Verbindung zu example.so.2 wo .2 ist die neueste Version. Wie funktioniert dann eine Anwendung in Abhängigkeit von einer älteren Version von example.so richtig identifizieren? Gibt es Regeln, welche Zahlen man verwenden muss? Oder ist das einfach Konvention? Ist es der Fall, dass im Gegensatz zu Windows, wo Software-Binärdateien zwischen Systemen übertragen werden, ein System, das über eine neuere Version eines freigegebenen Objekts verfügt, beim Kompilieren aus dem Quellcode automatisch mit der älteren Version verknüpft wird?

Ich vermute, dass dies mit ldconfig zusammenhängt, bin mir aber nicht sicher, wie.

127
user119

Binärdateien selbst wissen, von welcher Version einer gemeinsam genutzten Bibliothek sie abhängig sind, und fordern sie speziell an. Sie können ldd verwenden, um die Abhängigkeiten anzuzeigen. meine für ls sind:

$ ldd /bin/ls
    linux-gate.so.1 =>  (0xb784e000)
    librt.so.1 => /lib/librt.so.1 (0xb782c000)
    libacl.so.1 => /lib/libacl.so.1 (0xb7824000)
    libc.so.6 => /lib/libc.so.6 (0xb76dc000)
    libpthread.so.0 => /lib/libpthread.so.0 (0xb76c3000)
    /lib/ld-linux.so.2 (0xb784f000)
    libattr.so.1 => /lib/libattr.so.1 (0xb76bd000)

Wie Sie sehen können, zeigt es z.B. libpthread.so.0, Nicht nur libpthread.so.


Der Grund für die symbolische Verknüpfung liegt beim Linker. Wenn Sie direkt mit libpthread.so Verknüpfen möchten, geben Sie gcc das Flag -lpthread Und fügen das Präfix lib und .so Hinzu. Suffix automatisch. Sie können es nicht anweisen, das Suffix .so.0 Hinzuzufügen, daher verweist der symbolische Link auf die neueste Version der Bibliothek, um dies zu erleichtern

91
Michael Mrozek

Die Nummern in den gemeinsam genutzten Bibliotheken sind Konventionen, die unter Linux verwendet werden, um die API einer Bibliothek zu identifizieren. Typischerweise ist das Format:

libFOO.so.MAJOR.MINOR

Und wie Sie normalerweise bemerkt haben, gibt es einen symbolischen Link von libFOO.so zu libFOO.so.MAJOR.MINOR. ldconfig ist für die Aktualisierung dieses Links auf die neueste Version verantwortlich.

Der MAJOR wird normalerweise erhöht, wenn sich die API ändert (neue Einstiegspunkte werden entfernt oder die Parameter oder Typen geändert). Der MINOR wird normalerweise für Bugfix-Releases oder beim Einführen neuer APIs erhöht, ohne vorhandene APIs zu beschädigen.

Eine ausführlichere Diskussion finden Sie hier: Zerlegen gemeinsam genutzter Bibliotheken

61
miguel.de.icaza

Freigegebene Bibliotheken sollten nach folgendem Schema versioniert werden:

blah.so.X.Y.Z

wo

  • X = rückwärts inkompatible ABI-Version
  • Y = abwärtskompatible ABI-Version
  • Z = Nur interne Änderungen - keine Änderung des ABI

Normalerweise sehen Sie nur die erste Ziffer wie hello.so.1 weil die erste Ziffer das einzige ist, was benötigt wird, um die "Version" der Bibliothek zu identifizieren, da alle anderen Ziffern abwärtskompatibel sind.

ldconfig verwaltet eine Tabelle darüber, welche gemeinsam genutzten Bibliotheken auf einem System verfügbar sind und wo der Pfad zu dieser Bibliothek vorhanden ist. Sie können dies überprüfen, indem Sie Folgendes ausführen:

ldconfig -p

Wenn ein Paket für etwas wie Red Hat erstellt wird, werden die gemeinsam genutzten Bibliotheken, die in der Binärdatei aufgerufen werden, nachgeschlagen und als Abhängigkeiten des Pakets zur RPM-Erstellungszeit hinzugefügt. Wenn Sie das Paket installieren, prüft das Installationsprogramm daher, ob hello.so.1 wird auf dem System installiert, indem ldconfig überprüft wird.

Sie können die Abhängigkeiten eines Pakets anzeigen, indem Sie Folgendes tun:

rpm -qpR hello.rpm

Dieses System ermöglicht (im Gegensatz zu Windows) mehrere Versionen des hello.so auf einem System installiert und von verschiedenen Anwendungen gleichzeitig verwendet werden.

25
ascotan

libNAME.so ist der Dateiname, der vom Compiler/Linker verwendet wird, wenn zuerst nach einer durch -lNAME angegebenen Bibliothek gesucht wird. In einer gemeinsam genutzten Bibliotheksdatei befindet sich ein Feld namens SONAME. Dieses Feld wird festgelegt, wenn die Bibliothek selbst durch den Erstellungsprozess zum ersten Mal mit einem gemeinsam genutzten Objekt verknüpft wird. Dieser SONAME ist tatsächlich das, was ein Linker in einer ausführbaren Datei speichert, abhängig davon, dass das gemeinsam genutzte Objekt damit verknüpft ist. Normalerweise hat SONAME die Form libNAME.so.MAJOR und wird jedes Mal geändert, wenn die Bibliothek nicht mehr mit vorhandenen ausführbaren Dateien kompatibel ist, die mit ihr verknüpft sind, und beide Hauptversionen der Bibliothek können bei Bedarf installiert bleiben (obwohl nur eine für die Entwicklung angegeben wird as libNAME.so) Um ein einfaches Upgrade zwischen kleineren Versionen einer Bibliothek zu unterstützen, ist libNAME.so.MAJOR normalerweise ein Link zu einer Datei wie libNAME.so.MAJOR.MINOR. Eine neue Nebenversion kann installiert werden. Sobald der Link zur alten Nebenversion abgeschlossen ist, wird auf die neue Nebenversion verwiesen, die sofort alle neuen Ausführungen aktualisiert, um die aktualisierte Bibliothek zu verwenden. Siehe auch meine Antwort auf Linux, GNU GCC, ld, Versionsskripte und das ELF-Binärformat - Wie funktioniert es?

20
penguin359