Using dlopen() to load optional dependencies brings several advantages: programs can gracefully downgrade a feature when a library is not available, a

Search code, repositories, users, issues, pull requests...

submited by
Style Pass
2024-05-08 16:00:09

Using dlopen() to load optional dependencies brings several advantages: programs can gracefully downgrade a feature when a library is not available, and the shared library is only loaded into the process (and its ELF constructors are run) only when the requested feature is actually used. But it also has some drawbacks, and the main one is that it is harder to track a program's dependencies, since unlike build-time dynamic linking there will not be a mention in the ELF metadata. This specification aims to solve this problem by providing a standardized specification for a custom ELF note that can be used to list dlopen() dependencies.

This document will attempt to define a common metadata format specification, so that multiple implementers might use it when coding upstream software, and packagers might use it when building packages and setting dependencies.

The metadata will be embedded in a series of new, 4-byte-aligned, allocated, 0-padded, read-only ELF header sections, in a JSON array containing name-value objects, either one ELF note per dependency or as a single note listing multiple dependencies in the top-level array. Implementers working on parsing ELF files should not assume a specific list of names, but parse anything that is included in the section, and should look for the note using the note type. Implementers working on build tools should strive to use the same names, for consistency. The most common will be listed here.

Leave a Comment