Files
buildroot/package
Thomas Petazzoni b47a466bbd package/libxcrypt: make available only with glibc
libxcrypt has been added as a replacement for the libcrypt
implementation that was part of glibc, but dropped from glibc starting
from version 2.39.

However, libxcrypt was made available for all C libraries, and this is
unfortunately causing some problems as it can clash with the libcrypt
implementation provided by the C library.

In particular, linux-pam has been consistently failing with uclibc, in
BR2_PER_PACKAGE_DIRECTORIES=y builds, with the following build
failure:

opasswd.c: In function 'compare_password':
opasswd.c:133:27: error: invalid application of 'sizeof' to incomplete type 'struct crypt_data'

What happens is relatively tricky, but let's try to break it down:

- uclibc-ng install a stub libcrypt.a (no shared variant, as for
  shared libraries, everything is in libc.so), and crypt.h

- libxcrypt installs libcrypt.so.* and crypt.h

So there is no "clash" on the library itself, but there is a clash on
the header file.

Since we're using BR2_PER_PACKAGE_DIRECTORIES=y, when building
linux-pam, we are creating the per-package STAGING_DIR by copying the
STAGING_DIR of linux-pam dependencies, i.e both the libxcrypt
STAGING_DIR and the uclibc-ng STAGING_DIR. But the latter ends up
being copied last, which means that at the end of the day, we have in
the per-package STAGING_DIR of linux-pam:

- The libcrypt.so from libxcrypt
- The crypt.h header from uclibc-ng
- The libcrypt.a from uclibc-ng

When the ./configure script of linux-pam tests whether the library has
crypt_r(), it concludes that yes it's available: and indeed
libcrypt.so from libxcrypt has it.

So it tries to use 'struct crypt_data' and 'crypt_r()', but those are
not supported in uClibc-ng, and so cannot be found in the <crypt.h>
header. So even if the ./configure script and the linux-pam code has
some logic to fallback to crypt() if crypt_r() isn't available, this
fallback doesn't trigger because the installed libcrypt.so does have
crypt_r().

Basically what happens is that uclibc-ng + libxcrypt is a combo that
violates a golden rule of our BR2_PER_PACKAGE_DIRECTORIES=y
implementation: packages shouldn't overwrite files from each other.

To avoid this situation, we make libxcrypt only installable on
glibc. This isn't a problem because as of today, BR2_PACKAGE_LIBXCRYPT
is always selected "if BR2_TOOLCHAIN_USES_GLIBC".

It should be noted though that the case of an older glibc (which still
had its own internal libcrypt) + libxcrypt continues to exist. It's
less likely to cause trouble though, as the libcrypt implementations
are much more similar.

Fixes:

  http://autobuild.buildroot.net/results/560f66b0311d02dc884732221d6870ae3c38067c/

Note: we do not add a Config.in comment for this glibc dependency,
because libxcrypt really is a "replacement" library to fill in the
void left by libcrypt's removal from glibc. There isn't realy a point
showing "libxcrypt needs a toolchain w/ glibc", because with musl or
uclibc-ng, the libcrypt functionality is directly part of the C
library.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 5c0a91f729)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2025-01-09 10:50:50 +01:00
..
2024-09-10 22:49:23 +02:00
2024-08-20 23:23:43 +02:00
2024-09-10 22:49:25 +02:00
2024-08-20 23:33:05 +02:00
2024-11-10 19:33:08 +01:00
2024-10-24 21:29:45 +02:00
2024-11-11 21:20:17 +01:00
2024-10-29 21:25:30 +01:00
2024-10-02 23:43:13 +02:00
2024-10-31 13:51:13 +01:00
2024-10-29 19:34:34 +01:00
2024-10-28 15:42:34 +01:00
2024-11-06 20:50:27 +01:00
2024-09-10 22:49:36 +02:00
2024-11-09 16:29:09 +01:00
2024-09-10 22:49:39 +02:00
2024-09-06 21:05:52 +02:00
2024-10-28 22:02:43 +01:00
2024-10-26 16:53:15 +02:00
2024-09-03 23:32:38 +02:00
2024-08-26 18:28:55 +02:00
2024-08-23 19:29:09 +02:00
2024-10-26 23:25:56 +02:00
2024-09-25 19:33:59 +02:00
2024-09-10 22:49:53 +02:00
2024-09-11 21:41:18 +02:00
2024-12-12 20:37:04 +01:00
2024-10-28 22:05:49 +01:00
2024-10-25 20:53:11 +02:00
2024-10-06 22:46:35 +02:00
2024-09-14 10:19:18 +02:00
2024-10-02 23:18:12 +02:00
2024-10-24 21:29:38 +02:00
2024-09-15 12:53:02 +02:00
2024-10-06 22:46:49 +02:00
2024-09-14 20:16:42 +02:00
2024-09-14 11:22:38 +02:00
2024-10-26 22:59:30 +02:00
2024-09-14 11:22:39 +02:00
2024-09-14 15:54:39 +02:00
2024-09-25 19:34:09 +02:00
2024-10-06 15:55:01 +02:00
2024-09-25 19:34:13 +02:00
2024-09-14 15:54:51 +02:00
2024-08-20 23:35:59 +02:00
2024-10-19 20:11:51 +02:00
2024-10-25 21:04:03 +02:00
2024-11-06 21:15:36 +01:00
2024-10-24 21:29:36 +02:00
2024-10-26 15:33:37 +02:00
2024-11-06 20:43:35 +01:00
2024-09-15 14:50:13 +02:00
2024-10-31 19:11:10 +01:00
2024-08-27 18:59:26 +02:00
2024-10-28 22:14:34 +01:00
2024-10-02 23:38:55 +02:00
2024-09-14 11:20:06 +02:00
2024-10-07 08:30:48 +02:00
2024-10-27 19:13:52 +01:00
2024-12-12 22:29:30 +01:00
2024-10-27 19:14:10 +01:00
2024-09-06 21:05:52 +02:00
2024-12-12 22:29:33 +01:00
2024-12-28 11:29:42 +01:00
2024-10-02 23:09:22 +02:00
2024-10-10 10:00:22 +02:00
2024-12-28 11:30:28 +01:00
2024-12-12 22:29:35 +01:00
2024-10-22 23:16:20 +02:00
2024-10-29 19:40:40 +01:00
2024-10-31 18:45:48 +01:00
2024-12-14 12:03:17 +01:00
2025-01-09 10:17:26 +01:00
2024-11-10 19:33:08 +01:00
2024-10-02 22:34:13 +02:00