GNU/Linux >> LINUX-Kenntnisse >  >> Linux

Wie funktionieren SO-Nummern (Shared Object)?

Binärdateien selbst wissen, von welcher Version einer gemeinsam genutzten Bibliothek sie abhängen, und fordern sie gezielt an. Sie können ldd verwenden um die Abhängigkeiten zu zeigen; mine 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 den symbolischen Link liegt beim Linker. Wenn Sie gegen libpthread.so verlinken möchten direkt geben Sie gcc ein das Flag -lpthread , und es fügt die lib hinzu Präfix und .so Suffix automatisch. Sie können ihm nicht sagen, dass er .so.0 hinzufügen soll Suffix, sodass der symbolische Link auf die neueste Version der Bibliothek verweist, um dies zu erleichtern


Die Nummern in den gemeinsam genutzten Bibliotheken sind Konventionen, die in 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 dafür verantwortlich, diesen Link auf die neueste Version zu aktualisieren.

Der MAJOR wird normalerweise erhöht, wenn sich die API ändert (neue Einstiegspunkte werden entfernt oder die Parameter oder Typen geändert). Der MINOR-Wert wird normalerweise für Fehlerbehebungsversionen erhöht oder wenn neue APIs eingeführt werden, ohne dass vorhandene APIs beschädigt werden.

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


Shared Libraries sollten nach folgendem Schema versioniert werden:

blah.so.X.Y.Z

wo

  • X =abwärtsinkompatibles ABI-Release
  • Y =abwärtskompatibles ABI-Release
  • Z =Nur interne Änderungen - keine Änderung der 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 existiert. 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-Build-Zeit hinzugefügt. Wenn Sie das Paket installieren, wird das Installationsprogramm daher nachsehen, ob hello.so.1 wird auf dem System installiert, indem ldconfig markiert wird .

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

rpm -qpR hello.rpm

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


Linux
  1. Was ist NGINX? Wie funktioniert es?

  2. Wie man WordPress-Permalinks in Nginx zum Laufen bringt

  3. Wie funktionieren die Interna von Sudo?

  4. Wie kann man ein freigegebenes Verzeichnis per Sftp zugänglich machen?

  5. Wie bekomme ich Uuencode zum Laufen?

So zeigen Sie Zeilennummern in Vim / Vi an

So installieren Sie Gasterweiterungen in Virtualbox VM

So arbeiten Sie mit Ansible Provisioner in Vagrant

Wie funktioniert Swap-Speicher in Linux?

Gewusst wie:Einführung in die Programmierung – Objektorientierte Programmierung

So zeigen Sie Zeilennummern in Gedit an