readutmp: load libsystemd with dlopen instead of linking

[bluca]

coreutils is a core/essential package, that is pulled in every build chroot and so on. The functionality provided by libsystem is useful for full systems, but not so much for build systems or other such minimal environments.

Switch usage of the library to dlopen, so that it can be built in but runtime optional, and can be avoided if the specific functionality is not used, gracefully.

If libsystemd headers are available at build time stamp the ELF binaries using the ELF dlopen metadata format as defined by: https://uapi-group.org/specifications/specs/elf_dlopen_metadata/ so that packaging tools for rpm/deb can automatically derive dependencies for it.

[pixelb]

This would impact uptime, pinky, users, who, and the coreutils multi-call binary.
Is there a graceful fallback though if systemd wasn't installed?
For libselinux the functionality is less core, but for reading utmp, that essentially what the above command do right?
BTW this patch should be discussed on bug-gnulib@gnu.org

thanks

[bluca]

Is there a graceful fallback though if systemd wasn't installed?

If systemd is installed amd running, then libsystemd is guaranteed to be installed, as it's of course a hard dependency of systemd itself. So if the library is missing, then the feature would be a no-op anyway, as the system cannot be running on systemd by definition.

[bluca]

In terms of fallbacks, the current code unconditionally does only the logind api approach if that's enabled at build time, and fails if that fails. So if the library is missing, currently it fails. Do you want me to change this bit https://github.com/bluca/gnulib/blob/c3a50e2ba14fbe0862eb348976d17aaaca0b9166/lib/readutmp.c#L1129 to fallback to the older functionality instead?

[pixelb]

Right, so without a fallback these utils would just fail to work if copied to a chroot or whatever without libsystemd.
That's less useful than the libselinux case TBH. One could copy on the required utility level in that case, rather than all utilities in a particular package. I'm not suggesting to implement fallbacks, but maybe that's appropriate. In any case any change in this area should be discussed on bug-gnulib@gnu.org as Paul Eggert and Bruno Haible have much more knowledge in this area having developed the systemd adjustments relatively recently.

[bluca]

Right, so without a fallback these utils would just fail to work if copied to a chroot or whatever without libsystemd.

Please do note that this is already the case - if you try to run this in a chroot without systemd, it will fail. So the same result as status quo. That said, happy to implement a fallback in case of ENOSYS or so.

[bluca]

Added graceful fallback on dlopen failure, and also sent to bug-gnulib@gnu.org (or at least I have attempted to do so...)