Re: [Buildroot] [PATCH] linux: allow the user to respect Linux kernel defconfig's CONFIG_WERROR

Quentin Schulz via buildroot
2026-04-08T10:45:39Z

Hi Arnout,

On 4/7/26 8:56 PM, Arnout Vandecappelle wrote:
>
>
> On 25/03/2026 18:51, Quentin Schulz via buildroot wrote:
>> From: Quentin Schulz <quentin.schulz@cherry.de>
>>
>> Buildroot forcibly disables WERROR (and PPC_WERROR via
>> PPC_DISABLE_WERROR for PowerPC) for all kernels since commit
>> 6b56e0b4f09b ("linux: disable -Werror") for the former and 1713c3c344be
>> ("linux: disable Werror for powerpc kernels") for the latter.
>>
>> Some users (me :) ) may only build kernels within Buildroot and may be
>> required by audit companies to ensure that no warnings are generated
>> when building them. While we could look at the log manually and report
>> that indeed no warnings are seen, better not even build if there's a
>> warning and catch them as early as possible.
>>
>> Thus, let's allow the user to not override the WERROR state gotten from
>> the defconfig. It is left as force-disabled by default as upstream
>> Buildroot likely does not want to fail builds when bumping the
>> toolchains with newer warnings and no bandwidth to fix or backport fixes
>> for kernels for upstream Buildroot defconfigs.
>>
>> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
>> ---
>> I believe that commit 6b56e0b4f09b ("linux: disable -Werror") should
>> rather have disabled WERROR from ESP_HOSTED_LINUX_CONFIG_FIXUPS in
>> package/esp-hosted/esp-hosted.mk instead of disabling it for everybody.
>
>  Yeah, I agree with that. And even so, it should only be done if it's
> really needed.
>
>> I understand Buildroot not wanting to respect WERROR if in the kernel
>> defconfig to avoid additional friction when bumping toolchains, hence
>> why I made this into a Kconfig knob.
>
>  Not really - for the defconfigs, we can easily create board/linux-
> disable-werror.fragment and include that as a Kconfig fragment for all
> problematic defconfigs. Ideally though the error should be resolved in a
> more recent kernel.
>
>  So I'd tend to prefer to revert 6b56e0b4f09b (or perhaps move it to
> esp-hosted) rather than adding yet another weird Config.in option.
>

Works for me. Is there something you want me to check specifically
before sending a revert? I'll build esp-hosted with an updated version
of the Buildroot defconfigs that triggered the revert commit, to make
sure it isn't failing anymore. I'll build the Linux kernel and kernel
modules for upstream Buildroot defconfigs. That'll take some time but at
least we'll know for sure upstream defconfigs are fine. Looking at the
defconfigs, only very few kernel modules are actually part of Buildroot
upstream defconfigs:

configs/orangepi_lite_defconfig:BR2_PACKAGE_RTL8189FS=y
configs/orangepi_pc_plus_defconfig:BR2_PACKAGE_RTL8189FS=y
configs/mangopi_mq1rdw2_defconfig:BR2_PACKAGE_RTL8723DS=y
configs/sipeed_lichee_rv_dock_defconfig:BR2_PACKAGE_RTL8723DS=y
configs/sipeed_lichee_rv_dock_defconfig:BR2_PACKAGE_RTL8723DS_BT=y
configs/orangepi_zero_defconfig:BR2_PACKAGE_XR819_XRADIO=y

So that doesn't cover much of the 34 kernel modules I found with

git grep -l --full-name kernel-module package/ | xargs basename -a |
grep '.mk' | xargs basename -a -s .mk | sed 's/-/_/g' | tr '[:lower:]'
'[:upper:]' | sed 's/\(.*\)/BR2_PACKAGE_\1/'

BR2_PACKAGE_BATMAN_ADV
BR2_PACKAGE_CRYPTODEV_LINUX
BR2_PACKAGE_DAHDI_LINUX
BR2_PACKAGE_DTBOCFG
BR2_PACKAGE_EMLOG
BR2_PACKAGE_ESP_HOSTED
BR2_PACKAGE_FALCOSECURITY_LIBS
BR2_PACKAGE_KERNEL_MODULE_IMX_GPU_VIV
BR2_PACKAGE_FWTS
BR2_PACKAGE_GCNANO_BINARIES
BR2_PACKAGE_IGH_ETHERCAT
BR2_PACKAGE_LINUX_BACKPORTS
BR2_PACKAGE_LTTNG_MODULES
BR2_PACKAGE_MALI_DRIVER
BR2_PACKAGE_MDIO_TOOLS
BR2_PACKAGE_NVIDIA_DRIVER
BR2_PACKAGE_NXP_MWIFIEX
BR2_PACKAGE_OPENVMTOOLS
BR2_PACKAGE_OWL_LINUX
BR2_PACKAGE_PKG_KERNEL_MODULE
BR2_PACKAGE_RTL8188EU
BR2_PACKAGE_RTL8189ES
BR2_PACKAGE_RTL8189FS
BR2_PACKAGE_RTL8192EU
BR2_PACKAGE_RTL8723BU
BR2_PACKAGE_RTL8723DS
BR2_PACKAGE_RTL8812AU_AIRCRACK_NG
BR2_PACKAGE_RTL8821AU
BR2_PACKAGE_RTL8821CU
BR2_PACKAGE_RTL8822CS
BR2_PACKAGE_V4L2LOOPBACK
BR2_PACKAGE_WILC_DRIVER
BR2_PACKAGE_WIREGUARD_LINUX_COMPAT
BR2_PACKAGE_XR819_XRADIO
BR2_PACKAGE_ZFS

I guess I'll let people figure out which package needs to be patched and
how?

>  For 1713c3c344be, it's probably not worth to bother reverting that one
> (and trying to find out which defconfigs break due to it). Unless you
> also need PPC builds to comply?
>

I don't care about PPC :)

Cheers,
Quentin