systemd: patch runtime dlopen calls

This ensures that all the features that are implemented via dlopen(3)
are available (or explicitly deactivated) by pointing dlopen to the
absolute store path instead of relying on the linkers runtime lookup
code.

All of the dlopen calls have to be handled. When new ones are introduced
by upstream (or one of our patches) those must be explicitly declared,
otherwise the build will fail.

As of systemd version 247 we've seen a few errors like `libpcre2.… not
found` when using e.g. --grep with journalctl. Those errors should
become less unexpected now.

There are generally two classes of dlopen calls. Those that we want to
support and those that should be deactivated / unsupported. This change
enforces that we handle all dlopen calls explicitly. Meaning: There is
not a single dlopen call in the code source tree that we did not
explicitly handle.

In order to do this I introduced a list of attributes that maps from
shared object name to the package that contains them. The package can be
null meaning the reference should be nuked and the shared object will
never be loadable during runtime (because it points at an invalid store
path location).

0 files changed, 0 insertions, 0 deletions