Re: [PATCH v2] tools/compiler: match glibc 2.42 definition of __attribute_const__

[Andrew Morton <akpm@linux-foundation.org>]

On Thu,  2 Jul 2026 05:06:35 +0900 "Joy H.J. Lee" <rkr0k0r@gmail.com> wrote:

> glibc 2.42 added __attribute_const__ to sys/cdefs.h:
> 
>     # define __attribute_const__ __attribute__ ((__const__))
> 
> GCC 15 warns when a macro is redefined to a different replacement list
> (-Wbuiltin-macro-redefined). Since host tool Makefiles (resolve_btfids,
> objtool) pass -Werror, this conflict becomes fatal.
> 
> The warning is suppressed on standard native builds because GCC treats
> /usr/include as a system header path (-isystem), and macro-redefinition
> warnings from system headers are silently suppressed by GCC. It fires
> when glibc headers are on a regular include path (-I) instead, which
> is the case in cross-compilation setups such as NixOS, where the
> sysroot's glibc is passed explicitly via -I rather than -isystem.
> 
> Per (C11 6.10.3), identical replacement lists are accepted silently.
> Match the glibc definition exactly, including the space before "((", so
> the redefinition is accepted without warning regardless of whether
> glibc headers are treated as system or non-system includes.
> 
> ...
>
> --- a/tools/include/linux/compiler.h
> +++ b/tools/include/linux/compiler.h
> @@ -119,7 +119,7 @@
>  #define __read_mostly
>  
>  #ifndef __attribute_const__
> -# define __attribute_const__
> +# define __attribute_const__ __attribute__ ((__const__))
>  #endif
>  
>  #ifndef __maybe_unused

I'm thinking this should be backported into earlier kernels, so they
can be compiled successfully on glibc-2.42 systems.  Do you agree?