public inbox for linux-kbuild@vger.kernel.org
 help / color / mirror / Atom feed
From: Nathan Chancellor <nathan@kernel.org>
To: "Thomas Weißschuh" <linux@weissschuh.net>
Cc: Arnd Bergmann <arnd@arndb.de>, Nicolas Schier <nsc@kernel.org>,
	linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org,
	David Howells <dhowells@redhat.com>
Subject: Re: [PATCH RFC 5/5] kbuild: uapi: also test UAPI headers against C++ compilers
Date: Thu, 12 Mar 2026 01:15:18 -0700	[thread overview]
Message-ID: <20260312081518.GA3161678@ax162> (raw)
In-Reply-To: <20260308-kbuild-uapi-c-v1-5-86aae09a7f1d@weissschuh.net>

On Sun, Mar 08, 2026 at 10:24:05PM +0100, Thomas Weißschuh wrote:
> C++ language requirements differ from those of C.
> 
> Also test the headers against C++ compilers to make sure no errors
> creep in accidentally.
> 
> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
> ---
>  usr/include/Makefile | 28 ++++++++++++++++++++++++++++
>  1 file changed, 28 insertions(+)
> 
> diff --git a/usr/include/Makefile b/usr/include/Makefile
> index edeaf9d778c4..0e23aeace410 100644
> --- a/usr/include/Makefile
> +++ b/usr/include/Makefile
> @@ -10,6 +10,7 @@ UAPI_CFLAGS := -std=c90 -Werror=implicit-function-declaration
>  UAPI_ARCH := $(or $(HEADER_ARCH),$(SRCARCH))
>  
>  override c_flags = $(KBUILD_USERCFLAGS) $(UAPI_CFLAGS) -Wp,-MMD,$(depfile)
> +cxx_flags = $(filter-out -Wmissing-prototypes -Wstrict-prototypes -std=%, $(KBUILD_USERCFLAGS)) -std=c++98
>  
>  # The following are excluded for now because they fail to build.
>  #
> @@ -61,6 +62,27 @@ endif
>  # asm-generic/*.h is used by asm/*.h, and should not be included directly
>  no-header-test += asm-generic/%
>  
> +# The following are not compatible with C++.
> +#
> +# Do not add a new header to the list without legitimate reason.
> +# Please consider to fix the header first.
> +#
> +# Sorted alphabetically.
> +no-header-test-cxx += linux/auto_dev-ioctl.h
> +no-header-test-cxx += linux/map_to_14segment.h
> +no-header-test-cxx += linux/map_to_7segment.h
> +no-header-test-cxx += linux/netfilter/xt_sctp.h
> +no-header-test-cxx += linux/target_core_user.h
> +no-header-test-cxx += linux/vhost.h
> +no-header-test-cxx += linux/vhost_types.h
> +no-header-test-cxx += linux/virtio_net.h
> +no-header-test-cxx += linux/virtio_ring.h
> +no-header-test-cxx += scsi/fc/fc_els.h
> +
> +ifeq ($(UAPI_ARCH),x86)
> +no-header-test-cxx += asm/elf.h
> +endif
> +
>  # The following are using libc header and types.
>  #
>  # Do not add a new header to the list without legitimate reason.
> @@ -138,8 +160,12 @@ endif
>  
>  always-y := $(patsubst $(obj)/%.h,%.hdrtest, $(shell find $(obj) -name '*.h' 2>/dev/null))
>  
> +# $(cc-option) forces '-x c' which breaks '-x c++' detection.
> +cc-can-compile-cxx := $(call try-run,$(CC) -c -x c++ /dev/null -o "$$TMP", 1)

Include $(CLANG_FLAGS) here just in case clang cannot generate code for
the host target (I know, sounds weird, but I have seen people build
LLVM only targeting arm/arm64 with an x86_64 host...).

> +
>  target-libc = $(filter $(uses-libc), $*.h)
>  target-can-compile = $(filter-out $(no-header-test), $*.h)
> +target-can-compile-cxx = $(and $(cc-can-compile-cxx), $(target-can-compile), $(filter-out $(no-header-test-cxx), $*.h))
>  
>  hdrtest-flags = -fsyntax-only -Werror \
>  		-nostdinc -I $(obj) $(if $(target-libc), -I $(srctree)/usr/dummy-include)
> @@ -149,6 +175,8 @@ quiet_cmd_hdrtest = HDRTEST $<
>        cmd_hdrtest = \
>  		$(CC) $(c_flags) $(hdrtest-flags) -x c /dev/null \
>  			$(if $(target-can-compile), -include $< -include $<); \
> +		$(if $(target-can-compile-cxx), \
> +			$(CC) $(cxx_flags) $(hdrtest-flags) -x c++ /dev/null -include $<;) \
>  		$(PERL) $(src)/headers_check.pl $(obj) $<; \
>  		touch $@
>  
> 
> -- 
> 2.53.0
> 

  reply	other threads:[~2026-03-12  8:15 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-08 21:24 [PATCH RFC 0/5] kbuild: uapi: also test UAPI headers against C++ compilers Thomas Weißschuh
2026-03-08 21:24 ` [PATCH RFC 1/5] kbuild: uapi: move some compiler arguments out of the command definition Thomas Weißschuh
2026-03-08 21:24 ` [PATCH RFC 2/5] kbuild: uapi: move all include path flags together Thomas Weißschuh
2026-03-08 21:24 ` [PATCH RFC 3/5] kbuild: uapi: handle UML in architecture-specific exclusion lists Thomas Weißschuh
2026-03-08 21:24 ` [PATCH RFC 4/5] kbuild: uapi: provide a C++ compatible dummy definition of NULL Thomas Weißschuh
2026-03-08 21:24 ` [PATCH RFC 5/5] kbuild: uapi: also test UAPI headers against C++ compilers Thomas Weißschuh
2026-03-12  8:15   ` Nathan Chancellor [this message]
2026-03-12  8:16 ` [PATCH RFC 0/5] " Nathan Chancellor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260312081518.GA3161678@ax162 \
    --to=nathan@kernel.org \
    --cc=arnd@arndb.de \
    --cc=dhowells@redhat.com \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@weissschuh.net \
    --cc=nsc@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox