494ed4d6ee
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). |
||
|---|---|---|
| .. | ||
| bsd | ||
| darwin | ||
| linux | ||
| solo5 | ||
| windows | ||