[3/3] check-uapi: use dummy libc includes

  From: Arnd Bergmann <arnd@arndb.de>

Based on Thomas Weißschuh's series to kernel headers to no longer require
an installed libc when build testing the uapi headers, the same can now
be done for the scripts/check-uapi.sh script.

The only required change here is to add the  usr/dummy-include include
path.

Link: https://lore.kernel.org/lkml/20260227-kbuild-uapi-libc-v1-0-c17de0d19776@weissschuh.net/ [1]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 scripts/check-uapi.sh | 1 +
 1 file changed, 1 insertion(+)
  

On 2026-03-06 17:33:09+0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
> 
> Based on Thomas Weißschuh's series to kernel headers to no longer require
> an installed libc when build testing the uapi headers, the same can now
> be done for the scripts/check-uapi.sh script.
> 
> The only required change here is to add the  usr/dummy-include include
> path.
> 
> Link: https://lore.kernel.org/lkml/20260227-kbuild-uapi-libc-v1-0-c17de0d19776@weissschuh.net/ [1]
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  scripts/check-uapi.sh | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/scripts/check-uapi.sh b/scripts/check-uapi.sh
> index e4d120eb09e3..c8beec58871c 100755
> --- a/scripts/check-uapi.sh
> +++ b/scripts/check-uapi.sh
> @@ -191,6 +191,7 @@ do_compile() {
>  		  -fno-eliminate-unused-debug-types \
>  		  -g \
>  		  "-I${inc_dir}" \
> +		  "-Iusr/dummy-include" \

What about also using -nostdinc?

>  		  -include "$header" \
>  		  -
>  }

I have a similar (unfinished) patch flying around which also
uses usr/dummy-include from the different kernel versions
to avoid mismatches in case something gets removed there.
Not sure if it is worth it.


diff --git a/scripts/check-uapi.sh b/scripts/check-uapi.sh
index 955581735cb3..48d157ee5408 100755
--- a/scripts/check-uapi.sh
+++ b/scripts/check-uapi.sh
@@ -186,7 +186,9 @@ do_compile() {
                  -std=c90 \
                  -fno-eliminate-unused-debug-types \
                  -g \
+                 -nostdinc \
                  "-I${inc_dir}" \
+                 "-I${inc_dir}/../dummy-include" \
                  -include "$header" \
                  -
 }
@@ -197,6 +199,7 @@ run_make_headers_install() {
        local -r install_dir="$(get_header_tree "$ref")"
        make -j "$MAX_THREADS" ARCH="$ARCH" INSTALL_HDR_PATH="$install_dir" \
                headers_install > /dev/null
+       rsync -a usr/dummy-include/ "$install_dir"/dummy-include/
 }

 # Install headers for both git refs
  

On Fri, Mar 6, 2026, at 17:39, Thomas Weißschuh wrote:
> On 2026-03-06 17:33:09+0100, Arnd Bergmann wrote:
>>  		  -g \
>>  		  "-I${inc_dir}" \
>> +		  "-Iusr/dummy-include" \
>
> What about also using -nostdinc?

I just removed it from my version after I found it made no difference,
and I wanted to keep the changes shorter. I agree it's slightly cleaner.

> I have a similar (unfinished) patch flying around which also
> uses usr/dummy-include from the different kernel versions
> to avoid mismatches in case something gets removed there.
> Not sure if it is worth it.

Agreed, I certainly don't mind having your version either if
anyone cares enough. I suppose it would add a very small build time
overhead for the extra copy, but if it does help catch bugs it
would be worth the time.

    Arnd
  

On 2026-03-06 17:45:36+0100, Arnd Bergmann wrote:
> On Fri, Mar 6, 2026, at 17:39, Thomas Weißschuh wrote:
> > On 2026-03-06 17:33:09+0100, Arnd Bergmann wrote:
> >>  		  -g \
> >>  		  "-I${inc_dir}" \
> >> +		  "-Iusr/dummy-include" \
> >
> > What about also using -nostdinc?
> 
> I just removed it from my version after I found it made no difference,
> and I wanted to keep the changes shorter. I agree it's slightly cleaner.

Ack, your choice.

> > I have a similar (unfinished) patch flying around which also
> > uses usr/dummy-include from the different kernel versions
> > to avoid mismatches in case something gets removed there.
> > Not sure if it is worth it.
> 
> Agreed, I certainly don't mind having your version either if
> anyone cares enough. I suppose it would add a very small build time
> overhead for the extra copy, but if it does help catch bugs it
> would be worth the time.

It is less about catching bugs, those will already have been caught by
the header tests before. But if something is removed from the dummy
headers because it became unused, the old UAPI headers won't build
anymore against the new dummy-headers.


Thomas
  

Hi Arnd and Thomas,

On Sat, Mar 07, 2026 at 09:51:05AM +0100, Thomas Weißschuh wrote:
> On 2026-03-06 17:45:36+0100, Arnd Bergmann wrote:
> > On Fri, Mar 6, 2026, at 17:39, Thomas Weißschuh wrote:
> > > On 2026-03-06 17:33:09+0100, Arnd Bergmann wrote:
> > >>  		  -g \
> > >>  		  "-I${inc_dir}" \
> > >> +		  "-Iusr/dummy-include" \
> > >
> > > What about also using -nostdinc?
> > 
> > I just removed it from my version after I found it made no difference,
> > and I wanted to keep the changes shorter. I agree it's slightly cleaner.
> 
> Ack, your choice.
> 
> > > I have a similar (unfinished) patch flying around which also
> > > uses usr/dummy-include from the different kernel versions
> > > to avoid mismatches in case something gets removed there.
> > > Not sure if it is worth it.
> > 
> > Agreed, I certainly don't mind having your version either if
> > anyone cares enough. I suppose it would add a very small build time
> > overhead for the extra copy, but if it does help catch bugs it
> > would be worth the time.
> 
> It is less about catching bugs, those will already have been caught by
> the header tests before. But if something is removed from the dummy
> headers because it became unused, the old UAPI headers won't build
> anymore against the new dummy-headers.
> 
> 
> Thomas

Shall I wait some more days for a possible modified patch 3/3?
Otherwise I'd like to apply the series to kbuild-next-unstable.  

Thanks and kind regards,
Nicolas
  

On 2026-03-20 21:12:53+0100, Nicolas Schier wrote:
> On Sat, Mar 07, 2026 at 09:51:05AM +0100, Thomas Weißschuh wrote:
> > On 2026-03-06 17:45:36+0100, Arnd Bergmann wrote:
> > > On Fri, Mar 6, 2026, at 17:39, Thomas Weißschuh wrote:
> > > > On 2026-03-06 17:33:09+0100, Arnd Bergmann wrote:
> > > >>  		  -g \
> > > >>  		  "-I${inc_dir}" \
> > > >> +		  "-Iusr/dummy-include" \
> > > >
> > > > What about also using -nostdinc?
> > > 
> > > I just removed it from my version after I found it made no difference,
> > > and I wanted to keep the changes shorter. I agree it's slightly cleaner.
> > 
> > Ack, your choice.
> > 
> > > > I have a similar (unfinished) patch flying around which also
> > > > uses usr/dummy-include from the different kernel versions
> > > > to avoid mismatches in case something gets removed there.
> > > > Not sure if it is worth it.
> > > 
> > > Agreed, I certainly don't mind having your version either if
> > > anyone cares enough. I suppose it would add a very small build time
> > > overhead for the extra copy, but if it does help catch bugs it
> > > would be worth the time.
> > 
> > It is less about catching bugs, those will already have been caught by
> > the header tests before. But if something is removed from the dummy
> > headers because it became unused, the old UAPI headers won't build
> > anymore against the new dummy-headers.

> Shall I wait some more days for a possible modified patch 3/3?
> Otherwise I'd like to apply the series to kbuild-next-unstable.  

It is a somewhat theoretical issue and if it arises at some point we can
still fix it up. So this shouldn't block the patches.

For the series:

Reviewed-by: Thomas Weißschuh <linux@weissschuh.net>


Thomas
  

On Fri, Mar 20, 2026 at 09:31:07PM +0100, Thomas Weißschuh wrote:
> On 2026-03-20 21:12:53+0100, Nicolas Schier wrote:
> > On Sat, Mar 07, 2026 at 09:51:05AM +0100, Thomas Weißschuh wrote:
> > > On 2026-03-06 17:45:36+0100, Arnd Bergmann wrote:
> > > > On Fri, Mar 6, 2026, at 17:39, Thomas Weißschuh wrote:
> > > > > On 2026-03-06 17:33:09+0100, Arnd Bergmann wrote:
> > > > >>  		  -g \
> > > > >>  		  "-I${inc_dir}" \
> > > > >> +		  "-Iusr/dummy-include" \
> > > > >
> > > > > What about also using -nostdinc?
> > > > 
> > > > I just removed it from my version after I found it made no difference,
> > > > and I wanted to keep the changes shorter. I agree it's slightly cleaner.
> > > 
> > > Ack, your choice.
> > > 
> > > > > I have a similar (unfinished) patch flying around which also
> > > > > uses usr/dummy-include from the different kernel versions
> > > > > to avoid mismatches in case something gets removed there.
> > > > > Not sure if it is worth it.
> > > > 
> > > > Agreed, I certainly don't mind having your version either if
> > > > anyone cares enough. I suppose it would add a very small build time
> > > > overhead for the extra copy, but if it does help catch bugs it
> > > > would be worth the time.
> > > 
> > > It is less about catching bugs, those will already have been caught by
> > > the header tests before. But if something is removed from the dummy
> > > headers because it became unused, the old UAPI headers won't build
> > > anymore against the new dummy-headers.
> 
> > Shall I wait some more days for a possible modified patch 3/3?
> > Otherwise I'd like to apply the series to kbuild-next-unstable.  
> 
> It is a somewhat theoretical issue and if it arises at some point we can
> still fix it up. So this shouldn't block the patches.
> 
> For the series:
> 
> Reviewed-by: Thomas Weißschuh <linux@weissschuh.net>
> 
> 
> Thomas

ok, thanks!