Versioitumattomat dynaamiset jaetut objektit

Vakiokäytäntönä on, että kaikilla dynaamisilla jaetuilla objekteilla (DSO) on versioidut SONAME-nimet. Paketoijien TULISI työskennellä sellaisten ylävirran osien kanssa, joilla ei ole versioituja SONAME-nimiä, jotta tämä ominaisuus olisi mahdollinen. Tämä on ehdoton vaatimus, jos DSO on linkitetty eri ohjelmistojen välille.

This policy helps to ensure ABI compatibility when DSOs are dynamically linked between different software.

When Are Unversioned Dynamic Shared Objects Acceptable

Muutamat ehdot on täytettävä, jotta verkonhaltijoiden sallitaan pysyä versioimattomina.

  • The DSO MUST NOT be visible to the dynamic linker (i.e. the DSO does not show up in ldconfig -p output)

  • The DSO MUST be located in a private directory (i.e. not located directly in /usr/lib[64] or in another directory listed as a library path for the linker)

  • The DSO MUST NOT be linked against and is loaded at runtime by the implementing application (i.e. dlopen())

If these conditions are met, the unversioned DSOs do not need to be placed in a -devel package.

Implementation Details

Listed below is information for each known use-case for unversioned DSOs. Evaluate if your situation matches any of these and ask for any clarification by opening a ticket with the Fedora Packaging Committee.

Vulkan

The Vulkan ecosystem continues to grow in capabilities and adoption. One of the core concepts is the Vulkan Loader. This component is responsible for initializing the stack and includes loading unversioned DSOs, called Drivers and Layers.

Vulkan Drivers need to be visible to the default loader and are a special exception.

Drivers have the following requirements:

  • The DSO SHOULD be located in a private directory in /usr/lib[64] (i.e. %{_libdir}/%{name}/driver)

  • The directory SHOULD be added to the loader path using a ld.conf.d configuration (i.e. %{_sysconfdir}/ld.conf.d/%{name}.conf definition)

Vulkan Layers are loaded by configuration as defined by the Vulkan Loader specification.

Layers have the following requirements:

  • The DSO MUST be located in a private directory in /usr/lib[64] (i.e. %{_libdir}/%{name}/layer) and loaded by configuration

OpenXR

The OpenXR ecosystem enables users to run XR applications built against the SDK. One of the core concepts is the OpenXR Loader. This component is responsible for initializing the stack and includes loading unversioned DSOs, called Runtimes and Layers.

OpenXR Runtimes are loaded by configuration as defined by the OpenXR Loader specification.

Runtimes have the following requirements:

  • The DSO MUST be located in a private directory in /usr/lib[64] (i.e. %{_libdir}/%{name}/runtime)

  • The directory SHOULD be added to the loader path using a ld.conf.d configuration (i.e. %{_sysconfdir}/ld.conf.d/%{name}.conf definition)

OpenXR Layers are loaded by configuration as defined by the OpenXR Loader specification.

Layers have the following requirements:

  • The DSO MUST be located in a private directory in /usr/lib[64] (i.e. %{_libdir}/%{name}/layer) and loaded by configuration

Other Cases

An example of another case is an unversioned DSO that is loaded at runtime within the same application. This allows an application to load an optional feature, ship modular capabilities, or otherwise dlopen() it’s own capabilities. These are allowed as long as the main requirements are met.

Want to help? Learn how to contribute to Fedora Docs ›