[PATCH RFC next 15/18] kbuild: enable -Werror for hostprogs

[Simon Glass]

Hi Quentin,

On Tue, 5 May 2026 at 04:52, Quentin Schulz <quentin.schulz at cherry.de> wrote:
>
> Hi Simon,
>
> On 5/4/26 10:38 PM, Simon Glass wrote:
> > Hi Quentin,
> >
> > On 2026-05-04T13:20:27, Quentin Schulz <foss+uboot at 0leil.net> wrote:
> >> kbuild: enable -Werror for hostprogs
> >>
> >> [ Upstream commit 27758d8c2583d10472b745a43ff86fef96c11ef7 ]
> >>
> >> Original commit log:
> >>
> >>    The hostprog compilers and linkers do not share the regular compiler flags,
> >>    so they are not affected by CONFIG_WERROR or W=e. As hostprogs are used
> >>    during the bootstrap of the build, they can't depend on kconfig options.
> >>
> >>    Enable -Werror unconditionally.
> >>
> >> Signed-off-by: Quentin Schulz <quentin.schulz at cherry.de>
> >>
> >> scripts/Makefile.extrawarn | 5 +++++
> >>   1 file changed, 5 insertions(+)
> >
> >> diff --git a/scripts/Makefile.extrawarn b/scripts/Makefile.extrawarn
> >> @@ -109,3 +109,8 @@ KBUILD_LDFLAGS            += --fatal-warnings
> >>   KBUILD_RUSTFLAGS     += -Dwarnings
> >>
> >>   endif
> >> +
> >> +# Hostprog flags are used during build bootstrapping and can not rely on CONFIG_ symbols.
> >> +KBUILD_HOSTCFLAGS    += -Werror
> >> +KBUILD_HOSTLDFLAGS   += -Wl,--fatal-warnings
> >> +KBUILD_HOSTRUSTFLAGS += -Dwarnings
> >
> > Just to check, is there a reason to keep this and patch 16 separate?
>
> Backports from Linux kernel where they already are separate.
>
> > The next patch immediately undoes the 'unconditionally' claim made
> > here. Anyone bisecting through this point gets host tools failing on
> > any new compiler warning, with no way to opt out short of
> > HOSTCFLAGS=-Wno-error - squashing would also let you drop the comment
> > that patch 16 then has to rewrite.
> >
>
> Fair enough.
>
> > If you'd rather keep them split to preserve upstream history, you
> > could mention in the commit message that the next patch makes it
> > conditional.
> >
>
> I would prefer to, it should make it easier to then see which patches
> were backported or not (git log --oneline). But I understand this
> unnecessarily breaks bisectability, so no strong opinion.

Same here, up to you.

Regards,
Simon