Nicht versionierte dynamische gemeinsam genutzte Objekte (DSOs)
Die Standardrichtlinie sieht versionierte SONAMES für alle dynamischen gemeinsam genutzten Objekte (DSOs) vor. Paketierer sollten mit den Upstream-Entwicklern, die keine versionierten SONAMES verwenden, zusammenarbeiten, um diese Funktionalität zu aktivieren. Dies ist zwingend erforderlich, wenn das DSO zwischen verschiedenen Softwareanwendungen gelinkt wird.
Diese Richtlinie trägt dazu bei, die ABI-Kompatibilität sicherzustellen, wenn DSOs dynamisch zwischen verschiedenen Softwareprogrammen gelinkt werden.
Wann unversionierte dynamische gemeinsam genutzte Objekte akzeptabel sind
Es müssen einige Bedingungen erfüllt sein, damit DSOs unversioniert bleiben dürfen.
-
Das DSO DARF für den dynamischen Linker NICHT sichtbar sein (d.h. das DSO wird nicht in der Ausgabe von
ldconfig -pangezeigt) -
Die DSO-Datei „MUSS“ sich in einem privaten Verzeichnis befinden (d.h. nicht direkt in /usr/lib[64] oder in einem anderen Verzeichnis, das als Bibliothekspfad für den Linker angegeben ist)
-
Das DSO DARF NICHT verlinkt werden und wird von der implementierenden Anwendung zur Laufzeit geladen (d.h. mit
dlopen())
Sind diese Bedingungen erfüllt, müssen die nicht versionierten DSOs nicht in ein -devel-Paket ausgelagert werden.
Implementierungsdetails
Nachfolgend finden Sie Informationen zu allen bekannten Anwendungsfällen für nicht versionierte DSOs. Prüfen Sie, ob Ihre Situation einem dieser Fälle entspricht, und wenden Sie sich bei Unklarheiten an das Fedora Packaging Committee, um ein Ticket zu eröffnen.
Vulkan
Das Vulkan-Ökosystem entwickelt sich stetig weiter und gewinnt zunehmend an Bedeutung. Eine der Kernkomponenten ist der Vulkan Loader. Diese Komponente initialisiert den Stack und lädt versionierte DSOs, sogenannte Treiber und Layer.
Vulkan-Treiber müssen für den Standard-Loader sichtbar sein und stellen eine besondere Ausnahme dar.
Treiber müssen die folgenden Anforderungen erfüllen:
-
Das DSO SOLLTE sich in einem privaten Verzeichnis in /usr/lib[64] befinden (d.h.
%{_libdir}/%{name}/Treiber) -
Das Verzeichnis SOLLTE mithilfe einer „ld.conf.d“-Konfiguration (d. h. „%{_sysconfdir}/ld.conf.d/%{name}.conf“-Definition) zum Loader-Pfad hinzugefügt werden
Vulkan-Layer werden gemäß der Vulkan Loader-Spezifikation durch die Konfiguration geladen.
Layer müssen die folgenden Anforderungen erfüllen:
-
Das DSO MUSS sich in einem privaten Verzeichnis in /usr/lib[64] befinden (d.h.
%{_libdir}/%{name}/layer) und über die Konfiguration geladen werden
OpenXR
Das OpenXR-Ökosystem ermöglicht es Nutzern, XR-Anwendungen auszuführen, die mit dem SDK erstellt wurden. Eine der Kernkomponenten ist der OpenXR Loader. Diese Komponente ist für die Initialisierung des Stacks zuständig und lädt unter anderem versionierte DSOs, sogenannte Runtimes und Layers.
OpenXR-Runtime werden gemäß der OpenXR Loader-Spezifikation durch die Konfiguration geladen.
Runtimes haben folgende Anforderungen:
-
Das DSO MUSS sich in einem privaten Verzeichnis in /usr/lib[64] befinden (d.h.
%{_libdir}/%{name}/runtime) -
Das Verzeichnis SOLLTE mithilfe einer „ld.conf.d“-Konfiguration (d. h. „%{_sysconfdir}/ld.conf.d/%{name}.conf“-Definition) zum Loader-Pfad hinzugefügt werden
OpenXR-Layer werden gemäß der OpenXR Loader-Spezifikation durch die Konfiguration geladen.
Layer müssen die folgenden Anforderungen erfüllen:
-
Das DSO MUSS sich in einem privaten Verzeichnis in /usr/lib[64] befinden (d.h.
%{_libdir}/%{name}/layer) und über die Konfiguration geladen werden
Weitere Fälle
Ein weiteres Beispiel ist ein nicht versioniertes DSO, das zur Laufzeit innerhalb derselben Anwendung geladen wird. Dadurch kann eine Anwendung optionale Funktionen laden, modulare Funktionen bereitstellen oder anderweitig eigene Funktionen mit dlopen() einbinden. Dies ist zulässig, solange die Hauptanforderungen erfüllt sind.
Want to help? Learn how to contribute to Fedora Docs ›