[Buildroot] Analysis of host-libxcrypt build failures

[Buildroot] Analysis of host-libxcrypt build failures

[Thomas Petazzoni]

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
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] Analysis of host-libxcrypt build failures

[Thomas Petazzoni via buildroot]

On Tue, 31 Dec 2024 17:12:49 +0100
Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:

> 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/20250101202112.1845113-1-thomas.petazzoni@bootlin.com/

> 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.

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
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot