Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Chen Pei <cp0613@linux.alibaba.com>
To: buildroot@buildroot.org
Cc: ju.o@free.fr
Subject: [Buildroot] [PATCH] package/ndctl: Needs toolchain w/ glibc or musl
Date: Sun,  8 Nov 2026 01:03:09 +0800	[thread overview]
Message-ID: <20261107170309.1045-1-cp0613@linux.alibaba.com> (raw)

Add a !BR2_TOOLCHAIN_USES_UCLIBC dependency to BR2_PACKAGE_NDCTL and list
glibc or musl in the accompanying comment, so ndctl is no longer offered on
uClibc-ng toolchains where it fails to build.

Fixes: https://autobuild.buildroot.org/results/2e698b5d818ba6af65f1b3c3c5246ffa6ae7ad8b/
Signed-off-by: Chen Pei <cp0613@linux.alibaba.com>
---
 package/ndctl/Config.in | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

Build failure (microblazeel + uClibc-ng, autobuild random config). All 14
failed ninja targets are these three errors, there is no other cause:

  ../ccan/endian/endian.h:71:24: error: expected identifier or '(' before '__extension__'
     71 | static inline uint16_t bswap_16(uint16_t val)
  ../ccan/endian/endian.h:84:24: error: redefinition of '__bswap_32'
     84 | static inline uint32_t bswap_32(uint32_t val)
  ../ccan/endian/endian.h:100:24: error: redefinition of '__bswap_64'
    100 | static inline uint64_t bswap_64(uint64_t val)

  In file included from .../usr/include/bits/byteswap-common.h:34,
                   from .../usr/include/bits/byteswap.h:1,
                   from .../usr/include/byteswap.h:22,
                   from .../usr/include/endian.h:59,
                   from .../usr/include/bits/waitstatus.h:72,
                   from .../usr/include/stdlib.h:42,
                   from ../ndctl/lib/nfit.c:3:

Why only uClibc-ng: the vendored ccan/endian/endian.h guards its own
bswap_16/32/64 inline functions with HAVE_BYTESWAP_H and HAVE_BSWAP_64, but the
meson build never sets either symbol (config.h.meson has no entry for them and
check_headers in meson.build does not look for byteswap.h), so the fallbacks are
always compiled. On uClibc-ng, <stdlib.h> pulls in <bits/waitstatus.h> ->
<endian.h> -> <byteswap.h>, and byteswap.h spells bswap_16/32/64 as
function-like macros, so any file including <stdlib.h> before the ccan header
gets its definition macro-expanded into a redefinition of __bswap_16/32/64.
glibc's <endian.h> includes only <bits/byteswap.h> (inline functions, no
bswap_* macros) and musl's <endian.h> does not include <byteswap.h> at all,
hence glibc and musl builds are unaffected.

Why this dependency instead of a patch: ndctl is userspace tooling for
NVDIMM/CXL persistent memory (libnvdimm, ACPI NFIT, CXL) and already depends on
udev, an MMU, threads, headers >= 5.10 and dynamic libraries. There is no
realistic persistent-memory platform running uClibc-ng, so nothing that could
be built and tested is lost by hiding the package there, whereas patching
vendored ccan code would add a local patch to carry (ndctl itself never calls
bswap_*(), the helpers only exist because the whole header is vendored).

diff --git a/package/ndctl/Config.in b/package/ndctl/Config.in
index 79bae61ebb..e9cd8d1b47 100644
--- a/package/ndctl/Config.in
+++ b/package/ndctl/Config.in
@@ -1,6 +1,7 @@
 config BR2_PACKAGE_NDCTL
 	bool "ndctl"
 	depends on BR2_PACKAGE_HAS_UDEV
+	depends on !BR2_TOOLCHAIN_USES_UCLIBC
 	depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_5_10 # __struct_group()
 	depends on BR2_TOOLCHAIN_HAS_SYNC_4 # json-c
 	depends on BR2_TOOLCHAIN_HAS_THREADS
@@ -20,10 +21,11 @@ config BR2_PACKAGE_NDCTL
 
 	  https://github.com/pmem/ndctl
 
-comment "ndctl needs udev /dev management, a toolchain w/ threads, headers >= 5.10, dynamic library"
+comment "ndctl needs udev /dev management, a toolchain w/ threads, headers >= 5.10, dynamic library, glibc or musl"
 	depends on BR2_USE_MMU
 	depends on BR2_TOOLCHAIN_HAS_SYNC_4
 	depends on !BR2_PACKAGE_HAS_UDEV \
 		|| !BR2_TOOLCHAIN_HAS_THREADS \
 		|| !BR2_TOOLCHAIN_HEADERS_AT_LEAST_5_10 \
-		|| BR2_STATIC_LIBS
+		|| BR2_STATIC_LIBS \
+		|| BR2_TOOLCHAIN_USES_UCLIBC

base-commit: acda85c85827c123a5238f3628009d8ae3ec0735
-- 
2.50.1

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

                 reply	other threads:[~2026-11-07 17:04 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261107170309.1045-1-cp0613@linux.alibaba.com \
    --to=cp0613@linux.alibaba.com \
    --cc=buildroot@buildroot.org \
    --cc=ju.o@free.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox