systemd's src/include/musl/limits.h override sits first on the include path and relies on '#include_next <limits.h>' to pull in the C library's definitions. Because <limits.h> is a compiler-provided fixed header (with a two-pass '#include_next' guarded by _GCC_LIMITS_H_), the override overshoots musl's <limits.h> and its feature-guarded POSIX limits (PATH_MAX, NAME_MAX, HOST_NAME_MAX, IOV_MAX, LINE_MAX, PIPE_BUF, PTHREAD_STACK_MIN, SSIZE_MAX, ...) are never defined, so every musl build (-Dlibc=musl) fails to compile.
Add a patch to the override defining the POSIX limits systemd references with musl's canonical values, each #ifndef-guarded so glibc is unaffected. Applied for libc-musl only. Upstream-Status: Submitted [https://github.com/systemd/systemd/pull/43824] Signed-off-by: Jaipaul Cheernam <[email protected]> --- ...X-limits-missing-from-limits.h-overr.patch | 92 +++++++++++++++++++ meta/recipes-core/systemd/systemd_261.3.bb | 6 ++ 2 files changed, 98 insertions(+) create mode 100644 meta/recipes-core/systemd/systemd/0001-musl-define-POSIX-limits-missing-from-limits.h-overr.patch diff --git a/meta/recipes-core/systemd/systemd/0001-musl-define-POSIX-limits-missing-from-limits.h-overr.patch b/meta/recipes-core/systemd/systemd/0001-musl-define-POSIX-limits-missing-from-limits.h-overr.patch new file mode 100644 index 00000000000..3ebe9885e35 --- /dev/null +++ b/meta/recipes-core/systemd/systemd/0001-musl-define-POSIX-limits-missing-from-limits.h-overr.patch @@ -0,0 +1,92 @@ +From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001 +From: Jaipaul Cheernam <[email protected]> +Date: Mon, 21 Sep 2026 10:24:40 +0000 +Subject: [PATCH] musl: define POSIX limits missing from limits.h override + +src/include/musl/limits.h sits first on the include path (-isystem +src/include/musl) and, like the sibling overrides, relies on +'#include_next <limits.h>' to pull in the C library's definitions. This +works for <stdlib.h>, <string.h>, etc., but not for <limits.h>: the compiler +ships its own <limits.h>, which reaches the C library header via a two-pass +'#include_next' guarded by _GCC_LIMITS_H_. With this override in the first +search-path slot, that chain overshoots musl's <limits.h> and never includes +it, so musl's feature-guarded POSIX limits are missing and every musl build +(-Dlibc=musl) fails, e.g. 'NAME_MAX'/'PATH_MAX'/'SSIZE_MAX' undeclared. + +Reordering the -isystem paths does not help, since <limits.h> is a +compiler-provided fixed header. Define the POSIX limits systemd references, +using musl's canonical values from its include/limits.h, each #ifndef-guarded +so glibc and toolchains that do reach musl's <limits.h> are unaffected. + +Upstream-Status: Submitted [https://github.com/systemd/systemd/pull/43824] +Signed-off-by: Jaipaul Cheernam <[email protected]> +--- + src/include/musl/limits.h | 52 +++++++++++++++++++++++++++++++++++++-- + 1 file changed, 50 insertions(+), 2 deletions(-) + +diff --git a/src/include/musl/limits.h b/src/include/musl/limits.h +index 9620a3b0acc..48fe0c68e89 100644 +--- a/src/include/musl/limits.h ++++ b/src/include/musl/limits.h +@@ -6,11 +6,59 @@ + #include <assert.h> + #include <sys/types.h> + ++/* When this override is first on the include search path (-isystem ++ * src/include/musl), '#include_next <limits.h>' reaches the compiler's own ++ * <limits.h>, which uses a two-pass '#include_next' sequence (guarded by ++ * _GCC_LIMITS_H_ via <syslimits.h>) to pull in the C library's <limits.h>. ++ * With this override occupying the first search-path slot, its own ++ * '#include_next' shifts the position the compiler's second-pass ++ * '#include_next' resolves from, so the chain overshoots musl's <limits.h> ++ * and never includes it. The POSIX limits musl defines in its ++ * feature-test-macro guarded section are therefore missing. This differs ++ * from the sibling overrides in this directory (e.g. <stdlib.h>, <string.h>) ++ * because the compiler ships its own <limits.h> but not those; reordering ++ * the -isystem paths does not help. ++ * ++ * Provide the POSIX limits systemd relies on, using musl's canonical values ++ * (see musl's include/limits.h). Each is #ifndef-guarded so glibc, and any ++ * toolchain whose '#include_next' does reach musl's <limits.h>, are ++ * unaffected. */ ++#ifndef NAME_MAX ++# define NAME_MAX 255 ++#endif ++#ifndef PATH_MAX ++# define PATH_MAX 4096 ++#endif ++#ifndef HOST_NAME_MAX ++# define HOST_NAME_MAX 255 ++#endif ++#ifndef LINE_MAX ++# define LINE_MAX 4096 ++#endif ++#ifndef IOV_MAX ++# define IOV_MAX 1024 ++#endif ++#ifndef PIPE_BUF ++# define PIPE_BUF 4096 ++#endif ++#ifndef PTHREAD_STACK_MIN ++# define PTHREAD_STACK_MIN 2048 ++#endif ++#ifndef _POSIX_PATH_MAX ++# define _POSIX_PATH_MAX 256 ++#endif ++#ifndef _POSIX_TZNAME_MAX ++# define _POSIX_TZNAME_MAX 6 ++#endif ++ + /* musl defines SSIZE_MAX as LONG_MAX, so its type is always long. However, on 32-bit architectures, musl + * defines ssize_t as int. Strictly speaking, this is not a bug in musl. POSIX only requires SSIZE_MAX to + * evaluate to the maximum value representable by ssize_t; it does not require SSIZE_MAX itself to have type + * ssize_t. However, our code assumes that SSIZE_MAX has type ssize_t, as is the case with glibc. Cast the +- * value explicitly so that SSIZE_MAX has type ssize_t. */ ++ * value explicitly so that SSIZE_MAX has type ssize_t. The assert is guarded because SSIZE_MAX is only ++ * visible when <limits.h> actually supplied it (see above). */ ++#ifdef SSIZE_MAX + static_assert(SSIZE_MAX == LONG_MAX, ""); +-#undef SSIZE_MAX ++# undef SSIZE_MAX ++#endif + #define SSIZE_MAX ((ssize_t) LONG_MAX) diff --git a/meta/recipes-core/systemd/systemd_261.3.bb b/meta/recipes-core/systemd/systemd_261.3.bb index 1a256a598a8..9413bd7f46e 100644 --- a/meta/recipes-core/systemd/systemd_261.3.bb +++ b/meta/recipes-core/systemd/systemd_261.3.bb @@ -38,6 +38,12 @@ SRC_URI += "file://touchscreen.rules \ file://0003-Do-not-create-var-log-README.patch \ " +# systemd's src/include/musl/limits.h override sits first on the include path +# and relies on '#include_next <limits.h>', but the compiler's own two-pass +# limits.h consumes that chain so musl's POSIX limits (PATH_MAX, NAME_MAX, +# HOST_NAME_MAX, SSIZE_MAX, ...) are never defined, breaking every musl build. +SRC_URI:append:libc-musl = " file://0001-musl-define-POSIX-limits-missing-from-limits.h-overr.patch" + PAM_PLUGINS = " \ pam-plugin-unix \ pam-plugin-loginuid \
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#246323): https://lists.openembedded.org/g/openembedded-core/message/246323 Mute This Topic: https://lists.openembedded.org/mt/121354744/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
