Analysis of host-libxcrypt build failures
Hello,
For quite a while, host-libxcrypt has been failing to build in the autobuilders:
http://autobuild.buildroot.net/?reason=host-libxcrypt-%
We've had over 440 build failures already, and they all look like this:
*** ERROR: package host-libxcrypt installs executables without proper RPATH:
*** /home/autobuild/autobuild/instance-14/output-1/host/bin/perl5.38.2
*** /home/autobuild/autobuild/instance-14/output-1/host/bin/perl
which of course looks surprising as host-libxcrypt is not the package installing perl. I finally took the time to investigate this, and I understand what happens, but I'm not fully sure what it is the correct fix. So let's dive down into what happens:
- host-perl gets built, and installs host/bin/perl and host/bin/perl5.38.2. At this time, perl is linked with libc.so, libm.so, libcrypt.so, using the libcrypt.so from the host system.
The perl executable does not have a proper RPATH, but check-host-rpath does not complain because none of the libraries that perl is linked against (libc, libm, libcrypt) are in HOST_DIR/lib (see function elf_needs_rpath() in support/scripts/check-host-rpath)
- host-libxcrypt then builds, and installs host/lib/libcrypt.so. Then, the support/scripts/check-host-rpath runs after the installation of host-libxcrypt. This script checks all executables, not just the ones that have just been installed by the current package, so it does check perl and perl5.38.2 again.
The perl executable still does not have a proper RPATH, and it is still linked against libcrypt.so, which this time around is in HOST_DIR/lib, which from check-host-rpath point of view is wrong: the executable depends on a library provided by Buildroot's HOST_DIR, so the executable should have a RPATH that ensures the library in HOST_DIR/lib gets used.
The obvious thing to fix is to get the perl executable to have a proper RPATH of course.
However, this means in the scenario above that perl will be built/linked against the system libcrypt.so, and then after host-libxcrypt is built/installed, host/bin/perl will from this point on run with libcrypt.so in host/lib, which isn't really ideal. Should we make host-libxcrypt a mandatory dependency of host-perl? How do we detect this situation in other packages? Should check-host-rpath have instead a allow-list of libraries (libc, libm) for which we accept to use the system-provided ones, and for everything else (including libcrypt), we expect HOST_DIR/lib to provide them?
For the record, we have host-libxcrypt because host-systemd was failing to build on systems that have a recent glibc installed, but don't have libxcrypt installed system-wide.
Thoughts?
Best regards,
Thomas
Signature · 7 lines
Thomas Petazzoni, co-owner and CEO, Bootlin Embedded Linux and Kernel engineering and training https://bootlin.com _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
Quoted 2 lines · On Tue, 31 Dec 2024 17:12:49 +0100 Thomas Petazzoni…
The obvious thing to fix is to get the perl executable to have a proper RPATH of course.
I have sent a patch doing just this:
https://patchwork.ozlabs.org/project/buildroot/patch/[email protected]/
Quoted 10 lines
However, this means in the scenario above that perl will be built/linked against the system libcrypt.so, and then after host-libxcrypt is built/installed, host/bin/perl will from this point on run with libcrypt.so in host/lib, which isn't really ideal. Should we make host-libxcrypt a mandatory dependency of host-perl? How do we detect this situation in other packages? Should check-host-rpath have instead a allow-list of libraries (libc, libm) for which we accept to use the system-provided ones, and for everything else (including libcrypt), we expect HOST_DIR/lib to provide them?
Quoted 3 lines
For the record, we have host-libxcrypt because host-systemd was failing to build on systems that have a recent glibc installed, but don't have libxcrypt installed system-wide.
I wanted to test building host-perl on a system with libxcrypt installed, but I wasn't able to easily find a Docker container of a distro that doesn't have libxcrypt installed by default.
Thomas
Signature · 7 lines
Thomas Petazzoni, co-owner and CEO, Bootlin Embedded Linux and Kernel engineering and training https://bootlin.com _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot