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

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

[Joy H.J. Lee]

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.

Signed-off-by: Joy H.J. Lee <rkr0k0r@gmail.com>
---
 tools/include/linux/compiler.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/include/linux/compiler.h b/tools/include/linux/compiler.h
index f40bd2b04..f2f54b038 100644
--- 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
-- 
2.53.0

---

v2: expand commit message to clarify when the warning fires (-I vs 
    -isystem); apologies for the direct reply to Nathan on v1.

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

[Andrew Morton]

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?

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

[R0K0R rk]

2026년 7월 2일 (목) 13:52, R0K0R rk <rkr0k0r@gmail.com>님이 작성:
>
>
>
> 2026년 7월 2일 (목) 07:45, 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?


(Resending in plain text due to a mailing list HTML rejection.
Apologies for the duplicate.)

> Yes, I completely agree. This build issue occurs regardless of the
> kernel version, so backporting it to stable trees would be highly beneficial.
>
> Thank you!