2016-03-30 2 views
1

Ich versuche zu verstehen, wie Shared-Library-Versionen unter Linux verwaltet werden und wie diese beim Konfigurieren und Kompilieren eines Programms mit verschiedenen Versionen von Include-Dateien interagieren.Linux beherbergt mehrere Versionen einer gemeinsam genutzten Bibliothek, aber was ist mit?

Ich verstehe, dass ein System mehrere Versionen von gemeinsam genutzten Bibliotheken (.so Dateien) durch die erste Versionsnummer folgenden libxxx.so im Dateinamen unterscheiden kann, und dass verschiedene Programme möglicherweise mit verschiedenen Versionen der gleichen Bibliothek verknüpft wurden . Eine neue Version einer Bibliothek (.so. # Hat sich geändert) ist im Allgemeinen mit der vorherigen Version nicht kompatibel. (Versionsnummern nach dem ersten sind geringfügige Bibliotheksänderungen, die die Kompatibilität nicht beeinträchtigen).

Wenn ich ein älteres Programm kompiliere (oder neu kompiliere), das mit einer älteren Version einer Bibliothek verknüpft wurde, und wenn ich sowohl die älteren als auch die neueren Bibliotheken auf meinem System habe, scheint es keinen Mechanismus für die Verwaltung mehrerer zu geben Versionen der Include-Dateien, die jeder Bibliotheksversion zugeordnet sind. Obwohl ich die ältere Version der Bibliothek zur Verfügung habe, ohne die ältere Version der Include-Dateien, auf die ich verlinken kann, kann ich dieses Programm also wirklich nicht neu kompilieren. Ist das wahr?

Wenn ja, scheint die Unterstützung mehrerer Bibliotheksversionen von fragwürdigem Wert zu sein. Die Idee muss sein, dass die einzigen Benutzer alter Versionen von Bibliotheken Programme sind, die kompiliert wurden, als die alte Version aktuell war, und dass kein Programm jemals neu kompiliert werden sollte, es sei denn, alle Versionen aller Bibliotheken, mit denen es verbunden ist, sind die neuesten Versionen von diese Bibliotheken, die auf dem System installiert sind. Sobald eine neue Version einer Bibliothek installiert ist, können alle Programme, die die ältere Version verwenden, nicht mehr kompiliert werden (es sei denn, sie werden mit der neueren Bibliothek auf die neuere Version aktualisiert). Recht?

Oder gehen die Leute normalerweise damit um, ein separates Unterverzeichnis von Include-Dateien für jede Version jeder installierten Bibliothek beizubehalten, damit Programme mit den entsprechenden Include-Dateien und Bibliotheksversionen neu kompiliert werden können?

Antwort

1

Include-Dateien unterschiedlich von gemeinsam genutzten Bibliotheken behandelt werden:

  • Mit Bibliotheken gemeinsam genutzt, es wird ein Name sein, für Pakete Entwicklung zu verwenden, wenn Verknüpfung, die in eine Datei eine symbolische Verbindung ist, die hat eine spezifische soname (Name plus Version). Nach dem Verknüpfen hat ein Programm einen Verweis auf die Datei, die immer dann verwendet wird, wenn das Programm ausgeführt wird.

  • Include-Dateien können durch die Option -I für Include-Pfade unterschieden werden. Wenn mehrere nützliche Versionen einer Bibliothek vorhanden sind, können einige Entwickler die Versionen mit unterschiedlichen Verzeichnisnamen verpacken, um die zugehörigen Headerdateien zu speichern. Auf diese Weise können durch Ändern nur der Option -I beim Kompilieren die Build-Skripts mit einer bestimmten Version der Header arbeiten. Im Gegensatz zu Shared Libraries werden die Header-Dateien jedoch nur verwendet, wenn das Programm erstellt, das eine Bibliothek verwendet.

+0

Ja, danke. Eine Bibliotheksversion ist JEDERZEIT nützlich, wenn sie zuvor veröffentlicht und verwendet wurde. Daher sollte es üblich sein, die Include-Dateien jeder Version immer in einem separaten Verzeichnis zu packen. Die Unterscheidung zwischen ersten und nachfolgenden Versionsnummern ist sehr sinnvoll, wobei die erste eine Änderung der Schnittstelle anzeigt und die anderen kleine Änderungen anzeigen, die die Schnittstelle nicht beeinflussen. Bibliothekspakete sollten ein Include-Unterverzeichnis für jede erste Versionsnummer haben, aber ich habe das selbst nie gesehen. – tedtoal

Verwandte Themen