Re: [PATCH v3 6/6] perf hist: Remove keysym.h include from hist.h

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Unconditional inclusion of glibc-specific `<features.h>` breaks musl builds.
--

commit 7fe3edc4f61ded07ac7e2f802a9ada49f3daa101
Author: Ian Rogers <irogers@google.com>

perf hist: Remove keysym.h include from hist.h

This commit removes the keysym.h inclusion from hist.h since it isn't
related to the UI. It also addresses the transitive dependency issues by
directly including ui/keysyms.h in several core and UI files.

> diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
> index f208ff5132388..a4c014a1d28fe 100644
> --- a/tools/perf/builtin-annotate.c
> +++ b/tools/perf/builtin-annotate.c
> @@ -24,6 +24,7 @@
>  #include "arch/common.h"
>  #include "builtin.h"
>  #include "perf.h"
> +#include "ui/keysyms.h"

[Severity: Low]
Does this unconditional inclusion of "ui/keysyms.h" introduce a build
regression on musl libc systems when slang support is disabled?

Previously, "ui/keysyms.h" was guarded by #ifdef HAVE_SLANG_SUPPORT inside
hist.h. By including it unconditionally here, it pulls in
tools/perf/ui/libslang.h for all builds.

That header contains an unconditional inclusion of the glibc-specific
<features.h> header:

tools/perf/ui/libslang.h:
...
#include <features.h>
#ifndef HAVE_LONG_LONG
#define HAVE_LONG_LONG __GLIBC_HAVE_LONG_LONG
#endif
...

Since musl libc systems do not provide <features.h>, can this cause the build
to fail if slang is disabled?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260902154858.2078885-1-irogers@google.com?part=6