From: Yegor Yefremov via buildroot <buildroot@buildroot.org>
To: buildroot@buildroot.org
Cc: chakrabortyshubham66@gmail.com, thomas.petazzoni@bootlin.com,
Ricardo Martincoski <ricardo.martincoski@datacom.com.br>
Subject: [Buildroot] [PATCH] package/atop: fix musl build
Date: Wed, 30 Sep 2026 23:18:26 +0200 [thread overview]
Message-ID: <20260930211826.2349920-1-yegorslists@gmail.com> (raw)
From: Yegor Yefremov <yegorslists@googlemail.com>
Since the bump to version 2.13.0, atop fails to build with musl:
drawbar.c:2336:33: error: implicit declaration of function 'waddwstr'; did you mean 'waddstr'? [-Wimplicit-function-declaration]
(Before 2.13.0, the same configurations already failed earlier on
uClibc because _POSIX_C_SOURCE was defined without a value. Upstream
fixed that in 2.13.0 by giving it an explicit value, but the same
pattern remains for _XOPEN_SOURCE.)
ncurses only declares its wide-character API, including waddwstr(),
when NCURSES_WIDECHAR is set. If the application does not set it,
curses.h derives it from the feature test macros:
#if defined(_XOPEN_SOURCE_EXTENDED) || \
(defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE - 0 >= 500))
drawbar.c defines _XOPEN_SOURCE with an empty value, which makes the
check evaluate as 0 >= 500 and fail.
This only breaks with musl because of the C library's <features.h>,
which curses.h pulls in through <stdio.h> before doing the check.
glibc and uClibc both redefine _XOPEN_SOURCE to 700 and define
_XOPEN_SOURCE_EXTENDED whenever _GNU_SOURCE is set, which drawbar.c
does, so the empty definition gets fixed up. musl never modifies the
application's feature test macros, so the empty value reaches
curses.h and the wide-character prototypes are left out.
Add a patch that defines _XOPEN_SOURCE as 700, matching the
_POSIX_C_SOURCE value of 200809L that is already used.
Fixes:
- https://autobuild.buildroot.org/results/914c1d8fa0fc8bbef64e4a64d58e5941d0077a3e
- https://autobuild.buildroot.org/results/b91/b91ea0722202de0d1fdeeaeea167fd1b21b6d5d6
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
---
...xplicit-value-for-_XOPEN_SOURCE-macr.patch | 48 +++++++++++++++++++
1 file changed, 48 insertions(+)
create mode 100644 package/atop/0001-drawbar-define-explicit-value-for-_XOPEN_SOURCE-macr.patch
diff --git a/package/atop/0001-drawbar-define-explicit-value-for-_XOPEN_SOURCE-macr.patch b/package/atop/0001-drawbar-define-explicit-value-for-_XOPEN_SOURCE-macr.patch
new file mode 100644
index 0000000000..d526d58433
--- /dev/null
+++ b/package/atop/0001-drawbar-define-explicit-value-for-_XOPEN_SOURCE-macr.patch
@@ -0,0 +1,48 @@
+From 54799216beac63a195cd6d34b22476fc15a80295 Mon Sep 17 00:00:00 2001
+From: Yegor Yefremov <yegorslists@googlemail.com>
+Date: Wed, 30 Sep 2026 10:59:49 +0200
+Subject: [PATCH] drawbar: define explicit value for _XOPEN_SOURCE macro
+
+drawbar.c uses the wide-character curses function waddwstr(). ncurses
+only declares its wide-character API when NCURSES_WIDECHAR is set,
+which curses.h derives from the feature test macros:
+
+ #if defined(_XOPEN_SOURCE_EXTENDED) || \
+ (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE - 0 >= 500))
+
+drawbar.c defines _XOPEN_SOURCE without a value, so _XOPEN_SOURCE - 0
+evaluates to 0 and the check fails.
+
+With glibc and uClibc this goes unnoticed, because their <features.h>
+redefines _XOPEN_SOURCE to 700 (and defines _XOPEN_SOURCE_EXTENDED)
+whenever _GNU_SOURCE is set. musl does not touch the application's
+feature test macros, so the empty definition reaches curses.h
+unchanged and the build fails:
+
+drawbar.c:2336:33: error: implicit declaration of function 'waddwstr'; did you mean 'waddstr'? [-Wimplicit-function-declaration]
+
+Define _XOPEN_SOURCE as 700, which matches the already explicit
+_POSIX_C_SOURCE value of 200809L (both refer to POSIX.1-2008).
+
+Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
+Upstream: https://github.com/Atoptool/atop/pull/415
+---
+ drawbar.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drawbar.c b/drawbar.c
+index 651a81e..e4db0d6 100644
+--- a/drawbar.c
++++ b/drawbar.c
+@@ -104,7 +104,7 @@
+ // the other.
+ /////////////////////////////////////////////////////////////////////////////
+ #define _POSIX_C_SOURCE 200809L
+-#define _XOPEN_SOURCE
++#define _XOPEN_SOURCE 700
+ #define _GNU_SOURCE
+ #define _DEFAULT_SOURCE
+
+--
+2.34.1
+
--
2.34.1
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
next reply other threads:[~2026-09-30 21:18 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-30 21:18 Yegor Yefremov via buildroot [this message]
2026-10-10 10:01 ` [Buildroot] [PATCH] package/atop: fix musl build Thomas Perale via buildroot
2026-10-10 16:26 ` Julien Olivain via buildroot
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=20260930211826.2349920-1-yegorslists@gmail.com \
--to=buildroot@buildroot.org \
--cc=chakrabortyshubham66@gmail.com \
--cc=ricardo.martincoski@datacom.com.br \
--cc=thomas.petazzoni@bootlin.com \
--cc=yegorslists@googlemail.com \
/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