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

[R0K0R rk]

2026년 7월 2일 (목) 13:52, R0K0R rk <rkr0k0r@xxxxxxxxx>님이 작성:
>
>
>
> 2026년 7월 2일 (목) 07:45, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>님이 작성:
>>
>> On Thu,  2 Jul 2026 05:06:35 +0900 "Joy H.J. Lee" <rkr0k0r@xxxxxxxxx> 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!