Re: [Buildroot] [PATCH] package/atop: fix implicit waddwstr declaration

[Thomas Petazzoni via buildroot <buildroot@buildroot.org>]

Hello,

On Sat, Aug 15, 2026 at 09:11:19PM +0530, Shubham Chakraborty wrote:
> atop uses wide-character ncurses functions such as `waddwstr` (e.g., in
> drawbar.c). For `<curses.h>` to expose the prototypes for these wide-character
> functions, the `_XOPEN_SOURCE_EXTENDED` macro must be defined before the
> header is included.
> Without these macros defined, the preprocessor skips the function prototypes.
> 
> drawbar.c:2336:33: error: implicit declaration of function 'waddwstr'
> 
> This commit fixes the build failure by adding `-D_XOPEN_SOURCE_EXTENDED`
> and `-DNCURSES_WIDECHAR` to `ATOP_CFLAGS`, ensuring the ncurses headers
> correctly expose the required wide-character prototypes.
> 
> Fixes :
>  - https://autobuild.buildroot.org/results/b91/b91ea0722202de0d1fdeeaeea167fd1b21b6d5d6
> 
> Signed-off-by: Shubham Chakraborty <chakrabortyshubham66@gmail.com>

This is lacking the usual information of since when it is
happening. Was it working before? Yes/no? If it used to work and now
it breaks, why?

Based on https://autobuild.buildroot.net/?reason=atop-%25 it seems
like up to the bump to version 2.13.0 we had both a uclibc build
failure:

/home/thomas/autobuild/instance-1/output-1/host/i686-buildroot-linux-uclibc/sysroot/usr/include/features.h:167:22: error: operator '<' has no left operand
  167 | # if _POSIX_C_SOURCE < 200809L

and a musl build failure:


drawbar.c:2336:33: error: implicit declaration of function 'waddwstr'; did you mean 'waddstr'? [-Wimplicit-function-declaration]
 2336 |                                 waddwstr(w->win, L"┃");
      |                                 ^~~~~~~~
      |                                 waddstr

but now with the version bump this issue only happens with musl. So
why does it only happen with musl? Your analysis points to a problem
that would seem to be independent of the C library, but it apparently
isn't.

So again, I don't doubt that your patch fixes the build issue, but the
explanation is not convincing enough that what you're proposing is the
right solution. Indeed your explanation says that those defines are
ALWAYS needed to access waddwstr, but the simple fact that the package
seems to build fine with glibc and uclibc proves that this affirmation
is incorrect.

Could you do more research on this?

Thanks!

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