Wenn Sie gemeinsam genutzte Objekte (.so) erstellen, kümmern Sie sich normalerweise auch um Versionen, indem Sie Suffixe wie mylib.so.2.3.1 hinzufügen. Um sicherzustellen, dass Ihre Programme diese Bibliothek oder andere spätere Versionen laden können, erstellen Sie Links mit Namen
mylib.so -> mylib.so.2.3.1
mylib.so.2 -> mylib.so.2.3.1
mylib.so.2.3 -> mylib.so.2.3.1
Also stellt alles nach .so version.sub-version.build (oder ähnliches) dar. Außerdem ist es möglich, dass mehr als eine Version derselben Bibliothek mit diesem Schema koexistieren, und alles, was notwendig ist, um Programme auf die Verwendung einer bestimmten umzustellen Version müssen die entsprechenden Links vorhanden sein.
Dynamisch verknüpfte ELF-Binärdatei (ob eine andere Bibliothek oder eine ausführbare Datei) verwendet den Namen des gemeinsam genutzten Objekts oder soname um die Bibliothek zu identifizieren, mit der die ausführbare Datei bei der Ausführung verknüpft werden soll.
Wenn eine Bibliothek als gemeinsam genutzte ELF-Bibliothek erstellt wird, fügt der Verknüpfungseditor zur Kompilierzeit ein DT_SONAME-Feld in die ausführbare Datei ein, das den SONAME der Bibliothek in die Bibliothek selbst einfügt. Der DT_SONAME ist im ELF-Standard definiert als:
Dieses Element enthält den String-Tabellen-Offset eines nullterminierten Strings, der den Namen des gemeinsam genutzten Objekts angibt. Der Offset ist ein Index in die in DT_STRTAB eingetragene Tabelle Eintrag. Weitere Informationen zu diesen Namen finden Sie weiter unten unter „Gemeinsame Objektabhängigkeiten“.
Wenn also jetzt eine ausführbare Datei erstellt wird, wird der SONAME darin eingebettet. Wann die ausführbare Datei ausgeführt wird, wird vom Linker verwendet, um nach der Bibliothek in den Dateien an den vordefinierten Speicherorten für die dynamische Bibliothek zu suchen. Der vordefinierte Speicherort in Windows wäre überall dort, wo sich DLLs befinden. In Linux und Mac OS X und anderen mit System V kompatiblen Systemen wären sie /lib und /usr/lib und möglicherweise andere Spots, hängt vom verwendeten Linker ab und kann in den eigenen Konfigurationen des Linkers definiert werden.
In jedem Fall prüft der Linker, ob die im soname-Eintrag genannte Bibliothek an einer dieser Stellen vorhanden ist, wenn ja, wird er sie verwenden.
Beachten Sie, dass der Standard besagt, dass der Soname ein STRING ist und die Versionskonventionen nachträglich zu einem Defacto-Standard wurden und ungefähr so aussehen:
Machen Sie den Soname zu libmyname.so.A und machen Sie den Dateinamen der Bibliothek zu libmyname.so.A.B oder libmyname.so.A.B.C (unter MacOSX ist es libmyname.A.B.dylib). Erstellen Sie einen Softlink von libmyname.so.A.B[.C]? bis libmyname.so.A .
A bleibt gleich, während die ABI der Bibliothek gleich bleibt.
B (oder B.C ) wird zur Nebenversion.
Unter Linux ist es üblich, dass die Bibliotheksversion mit der Paketversionsnummer identisch ist. Das hat seine Vor- und Nachteile.
libtool-Formalisierung
GNU libtool wird häufig zum Erstellen dynamischer Bibliotheken verwendet und hat ein formelleres Versionierungssystem und eine starke Logik dafür. Das libtool-Versionierungssystem für Sonames funktioniert sehr gut und wird von komplexen Bibliotheken übernommen, um die Dinge übersichtlich zu halten.
Unter libtool ist die Versionierung wie unter:
libmylib-aktuell .freigeben .Alter
Unter libtool ist die Idee, dass Bibliotheken, wenn sie sich weiterentwickeln, Funktionalität hinzufügen und entfernen.
Angenommen, Sie entwickeln eine Bibliothek. Beginnen Sie mit einer Version als 0.0.0 .
Nehmen wir nun an, Sie beheben ein paar Fehler, Sie würden nur die Version erhöhen Nummer.
Der neue Name wäre also libmylib.0.1.0 oder libmylib.0.2.0 usw. für jede Veröffentlichung, die nur Fehler behebt, aber nichts an der ABI ändert.
Unterwegs sagst du. Pfui! Ich hätte diese Unterfunktionalität besser machen können, also fügen Sie einen neuen Satz von Funktionen hinzu, um etwas besser zu machen, aber weil andere immer noch Ihre Bibliothek verwenden, lassen Sie immer noch die alte (veraltete) Funktionalität dort.
Die Regeln lauten wie folgt:
-
Beginnen Sie mit Versionsinformationen von „0:0:0“ für jede libtool-Bibliothek.
-
Aktualisieren Sie die Versionsinformationen nur unmittelbar vor einer Veröffentlichung Ihrer Software. Häufigere Updates sind unnötig und garantieren nur, dass die aktuelle Schnittstellennummer schneller größer wird.
-
Wenn sich der Quellcode der Bibliothek seit der letzten Aktualisierung geändert hat, erhöhen Sie die Revision („c:r:a“ wird zu „c:r+1:a“).
-
Wenn seit der letzten Aktualisierung Schnittstellen hinzugefügt, entfernt oder geändert wurden, erhöhen Sie die aktuelle und setzen Sie die Revision auf 0.
-
Wenn seit der letzten öffentlichen Version Schnittstellen hinzugefügt wurden, erhöhen Sie das Alter.
-
Wenn seit der letzten Veröffentlichung Schnittstellen entfernt oder geändert wurden, setzen Sie das Alter auf 0.
Sie können mehr darüber in der libtool-Dokumentation lesen
Aktualisieren ...
Das Folgende war ein Kommentar, dass meine Erklärung einen Fehler enthält. Dies ist nicht der Fall, was etwas mehr Details erfordert, als in einen Antwortkommentar eingefügt werden können, siehe unten.
Ursprünglicher Einwand
Hier ist ein Fehler aufgetreten:Unter Linux ist die Version formlibmylib.(current-age).release.age, wobei die Klammern einen auszuwertenden Ausdruck angeben. Beispielsweise installiert GLPK 4.54 withcurrent:revision:age =37:1:1 unter Linux die Bibliotheksdatei libglpk.so.36.1.1. Weitere Informationen finden Sie z. B. unter
Widerlegung
TLDR:autotools.io ist keine autoritative Quelle. ErklärungWährend Flameeyes ein großartiger Entwickler und einer der Betreuer von Gentoo ist, war es er der den Fehler gemacht und eine lockere "Faustregel"-Interpretation der libtool-Spezifikation erstellt hat. Obwohl dies in 99 % der Fälle nicht zu Systemunterbrechungen führen wird, wenn wir der Ad-hoc-Methode zur Aktualisierung von aktuell folgen würden :
Die Faustregeln für den Umgang mit diesen Werten lauten:
Erhöhen Sie immer den Revisionswert.
Erhöhen Sie den aktuellen Wert, wenn eine Schnittstelle hinzugefügt, entfernt oder geändert wurde.
Erhöhen Sie den Alterswert nur, wenn die an der ABI vorgenommenen Änderungen abwärtskompatibel sind.
er sagt dann weiter, dass es am besten wäre, wenn man mehrere Versionen von Gtk pflegt, einfach die Bibliotheksversion an den Bibliotheksnamen anzuhängen und einfach die Versionsnummer auszugeben. (wie in GTK+):
In dieser Situation besteht die beste Option darin, einen Teil der Versionsinformationen der Bibliothek an den Namen der Bibliothek anzuhängen, was durch den Sonamen libglib-2.0.so.0 von Glib veranschaulicht wird. Dazu muss die Deklaration in theMakefile.am wie folgt lauten:
lib_LTLIBRARIES = libtest-1.0.la
libtest_1_0_la_LDFLAGS = -version-info 0:0:0
Nun, das ist nur ein schwachsinniger Ansatz, um die Leistung der dynamischen Verknüpfung und die Versionierung der Symbolauflösung völlig umstritten zu machen!. Er sagt, einfach abschalten. Pferde Popel! Kein Wunder, dass es selbst erfahrenen Entwicklern schwer fällt, Open-Source-Projekte zu erstellen und zu warten, und wir laufen ständig auf Binärdateien, die jedes Mal sterben, wenn neue Versionen von Bibliotheken installiert werden (weil sie sich gegenseitig verprügeln).
Der Versionierungsansatz von libtool ist SEHR DURCHDACHT . Es ist ein Algorithmus und seine Schritte sind geordnet Anleitung 1 bis 6 sind jedes Mal zu befolgen, wenn der Code einer dynamisch verknüpften Bibliothek aktualisiert wird.
Für neue und aktuelle Entwickler lesen Sie sie bitte sorgfältig durch und stellen Sie sich vor, was mit der Versionsnummer der Bibliothek während der gesamten Lebensdauer Ihrer erstaunlichen Software passieren wird. Wenn Sie dies tun, werden Sie feststellen, dass jede zuvor verlinkte Software wird immer die aktuellste und genaueste Version Ihrer erstaunlichen Bibliothek korrekt verwenden, und keine von ihnen werden jemals aufeinander schlagen oder stampfen, UND Sie müssen dem Namen Ihrer Bibliothek niemals eine blühende Zahl hinzufügen (es sei denn, dies ist zum Vergnügen oder aus ästhetischen Gründen).