Frage

Als ich ls -l in /usr/lib sehe ich eine Menge Libs mit "sameName.so.*.*" Erweiterung.

  1. Was ist die Bedeutung dieser Erweiterungen?
  2. Warum Softlinks erstellt werden? was sind ihre Verwendung?

Ein Beispiel wird helfen, eine Menge zu verstehen.

War es hilfreich?

Lösung

Dies ist ein Trick, um Version Shared Object-Dateien verwendet. Es ist ein Weg, um die gefürchtete DLL Hölle zu vermeiden, die wegen fauler Verknüpfung zustande kamen.

Der Vorteil faul Verknüpfung (oder späte Bindung) ist, dass Komponenten Ihrer ausführbare Datei kann wieder verknüpfen diese ausführbaren Dateien ohne tatsächlich geändert werden. Dies ermöglicht eine Fehlerbehebung in Komponenten von Drittanbietern, ohne eine neue ausführbare Datei zu versenden haben, unter anderem.

Der Nachteil ist genau der gleiche wie der Vorteil. Ihre ausführbare Datei kann, dass die Annahmen finden es über die zugrunde liegenden Bibliotheken vorgenommen wurden geändert und das ist wahrscheinlich alle möglichen Probleme verursachen.

Versionierung von Shared Objects ist ein Weg, dies zu vermeiden. Eine andere wäre, nicht Anteil an allen Objekten, aber das hat auch Vor-und Nachteile, die ich nicht in hier.

Als Beispiel, sagen wir, Sie haben Version 1 von xyz.so. Sie haben eine Datei und einen symbolischen Link zu dieser Datei:

pax> ls -al xyz*
-rw-r--r--  1 pax paxgroup    12345 Nov 18  2009 xyz.so.1
lrwxrwxrwx  1 pax paxgroup        0 Nov 18  2009 xyz.so -> xyz.so.1

Wenn Sie jetzt eine ausführbare Datei exe1 erstellen, verknüpft es mit xyz.so, wird es dem symbolischen Link folgen, so dass es xyz.so.1 in der ausführbaren Datei als das, was speichert es zur Laufzeit zu laden muss.

So, wenn Sie die gemeinsame Bibliothek aktualisieren so:

pax> ls -al xyz*
-rw-r--r--  1 pax paxgroup    12345 Nov 18  2009 xyz.so.1
-rw-r--r--  1 pax paxgroup    67890 Nov 18  2009 xyz.so.2
lrwxrwxrwx  1 pax paxgroup        0 Nov 18  2009 xyz.so -> xyz.so.2

Ihre ursprüngliche ausführbare exe1 wird noch load Version 1 des gemeinsamen Objekts.

können jedoch beliebige ausführbare Dateien erstellen Sie nun (wie exe2) wird mit der Version 2 des gemeinsamen Objekt verknüpft werden.


Die tatsächlichen Implementierungsdetails können etwas variieren (ich bin stütze meine Antwort auf früheren UNIX-Varianten und Linux erscheint Versionierung ein wenig intelligenten zu tun, als nur folgenden symbolische Links). IBM developer hat einen schönen Artikel darüber, wie es gemacht wird hier .

Wenn Sie ein gemeinsam genutztes Objekt erstellen, geben Sie es sowohl einen richtigen Namen und eine soname. Diese werden verwendet, um das gemeinsame Objekt zu installieren (die sowohl erstellt das Objekt und einen Link zu ihnen).

So können Sie mit der Situation am Ende können:

pax> ls -al xyz*
-rw-r--r--  1 pax paxgroup    12345 Nov 18  2009 xyz.so.1.5
lrwxrwxrwx  1 pax paxgroup        0 Nov 18  2009 xyz.so.1 -> xyz.so.1.5
lrwxrwxrwx  1 pax paxgroup        0 Nov 18  2009 xyz.so -> xyz.so.1

mit xyz.so.1.5 die SONAME von xyz.so.1 besitzen.

Wenn die Linker-Links in xyz.so, folgen dem Link der ganzen Weg nach xyz.so.1.5 und nutzen seine SONAME von xyz.so.1 zum Speichern in der ausführbaren Datei. Dann, wenn Sie run die ausführbare Datei, es versucht zu laden xyz.so.1, die zu einer bestimmten xyz.so.1.N Punkt (nicht unbedingt Version 1.5).

So Sie xyz.so.1.6 installieren könnten und aktualisieren Sie den xyz.so.1 Link zu Punkt, um es statt und bereits verknüpften ausführbaren Dateien würden, dass stattdessen verwenden.

Ein Vorteil dieser Multi-Layer-Methode ist, dass Sie mehrere potenziell inkompatible Bibliotheken mit dem gleichen Namen (xyz.so.1.*, xyz.so.2.*), aber innerhalb jeder Hauptversion haben, können Sie sie frei Upgrade , da sie eigentlich sind kompatibel sein .

Wenn Sie verknüpfen neue ausführbare Dateien:

  • Die mit xyz.so verbindet die letzte kleinere Version der letzten größeren Version.
  • Verknüpfung Andere mit xyz.so.1 die letzte kleinere Version einer bestimmten Hauptversion erhalten.
  • Wieder andere mit xyz.so.1.2 Verknüpfung wird eine bestimmte kleinere Version einer bestimmten Hauptversion erhalten.

Andere Tipps

Es ist ein Versionsschema für gemeinsam genutzte Bibliotheken . Jede Bibliothek sollte 3 Namen haben:

  1. Echter Name: der eigentliche Bibliotheksname, libfoo.so.1.2.3
  2. "SONAME": für den Namen in der ausführbaren Datei aufgezeichnet, und der Name dynamischen Linker sucht nach, libfoo.so.1.2. Dieser Name wird tatsächlich in der Bibliothek binär selbst geschrieben, und wird in der ausführbaren Datei zur Verknüpfungszeit aufgezeichnet werden. Es ist in der Regel ein symbolischer Link zu Bibliothek richtigen Namen (in der Regel der neueste Version).
  3. Linkers Name: der Name, den Sie an den Linker geben, wenn Ihr Programm aufzubauen. Normalerweise verbindet den neuesten SONAME.

Beispiel

Angenommen, Sie haben libfoo Version 1 installiert: libfoo.so -> libfoo.so.1.0 -> libfoo.so.1.0.0. Sie bauen Ihr Programm bar mit -lfoo. es verbindet jetzt zu libfoo und wird aufgrund SONAME libfoo.so.1.0 zur Laufzeit laden. Dann aktualisieren Sie auf eine gepatchte aber binärkompatibel libfoo.so.1.0.1 durch reale binäre ersetzen. bar noch Links zu libfoo.so.1.0 und muss nicht neu aufgebaut werden.

Nun stellen Sie ein neues Programm baz aufbauen wollen, die Vorteile inkompatible Änderungen in libfoo v1.1 nimmt. Sie installieren eine neue Version und Ihr System jetzt haben zwei parallel installierten Versionen:

  1. libfoo.so.1.0 -> libfoo.so.1.0.1
  2. libfoo.so -> libfoo.so.1.1 -> libfoo.so.1.1.0

Hinweis Linker Name auf die neueste Version aktualisiert wurde (dies ist die Version auf die Header, den Sie in /usr/include installiert ist).

Sie bauen baz, und es Links zu libfoo.so und lädt libfoo.so.1.1 zur Laufzeit. Nicht, dass bar läuft noch gegen libfoo.so.1.0 und muss nicht aktualisiert werden.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top