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: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
For testing in -next, as discussed in
https://lore.kernel.org/lkml/20250812-kbuild-werror-v1-2-36c9ff653700@linutronix.de/
---
scripts/Makefile.extrawarn | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/scripts/Makefile.extrawarn b/scripts/Makefile.extrawarn
index 96ff3f5582d651f0016c8ccd49d46022cc6fe070..1434cb6208cb82f20aeb29cc8c059220d1a1f6d2 100644
--- a/scripts/Makefile.extrawarn
+++ b/scripts/Makefile.extrawarn
@@ -224,3 +224,8 @@ KBUILD_USERLDFLAGS += -Wl,--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
--
2.50.1
"Thomas Weißschuh" <thomas.weissschuh@linutronix.de>: > Enable -Werror unconditionally Please, drop this patch. Never enable -Werror unconditionally for any part of build. I often bisect Linux. And to do this, I often need to build very old Linux commits (with modern compiler). Unconditional -Werror will make this impossible. For example, recently I found this regression: https://lore.kernel.org/regressions/197f290e30b.eaadc7bc7913.7315623184036672946@zohomail.com/T/#u The regression caused by commits happened in 2019. So to bisect it, I had to build 2019 trees using modern compiler. -- Askar Safin
Hi Askar, On Sun, Oct 05, 2025 at 04:10:47AM +0300, Askar Safin wrote: > "Thomas Weißschuh" <thomas.weissschuh@linutronix.de>: > > Enable -Werror unconditionally > > Please, drop this patch. This is already merged into Linus's tree so it cannot be dropped, it would need to be reverted. However... > Never enable -Werror unconditionally for any part of build. > > I often bisect Linux. And to do this, I often need to build very old > Linux commits (with modern compiler). Unconditional -Werror will make > this impossible. > > For example, recently I found this regression: > > https://lore.kernel.org/regressions/197f290e30b.eaadc7bc7913.7315623184036672946@zohomail.com/T/#u > > The regression caused by commits happened in 2019. > > So to bisect it, I had to build 2019 trees using modern compiler. I do my fair share of bisecting old Linux trees with a modern compiler, so I do understand that pain. While it is easy enough to avoid this behavior with HOSTCFLAGS=-Wno-error or HOSTCFLAGS=-w and there are other places that the kernel enables -Werror unconditionally, I do not want this to be a major pain point for random people doing bisected, especially when the host tools are fairly battle tested so warnings may not be a big deal. In looking further into this, I noticed that in its current state, -Werror is not getting applied to scripts/basic/fixup or scripts/kconfig/*.o files (seems $(include-y) happens to late?), which was one of the reasons to avoid making it depend on CONFIG_WERROR or W=e. If that's the case, we could probably make it opt in like the rest of the warnings for the kernel, which should be a fair compromise between wanting to make potential issues more obvious while not impacting people who build old sources with new compilers. Thomas and Nicolas, thoughts? Cheers, Nathan diff --git a/scripts/Makefile.extrawarn b/scripts/Makefile.extrawarn index 1434cb6208cb..1a29598cf7cb 100644 --- a/scripts/Makefile.extrawarn +++ b/scripts/Makefile.extrawarn @@ -223,9 +223,11 @@ KBUILD_USERCFLAGS += -Werror KBUILD_USERLDFLAGS += -Wl,--fatal-warnings KBUILD_RUSTFLAGS += -Dwarnings -endif - -# Hostprog flags are used during build bootstrapping and can not rely on CONFIG_ symbols. +# While hostprog flags are used during build bootstrapping (thus can not use on +# CONFIG_ symbols), -Werror should be opted into, so only apply -Werror to +# hostprogs built after the initial Kconfig bootstrap. KBUILD_HOSTCFLAGS += -Werror KBUILD_HOSTLDFLAGS += -Wl,--fatal-warnings KBUILD_HOSTRUSTFLAGS += -Dwarnings + +endif
On Sun, Oct 5, 2025 at 10:53 PM Nathan Chancellor <nathan@kernel.org> wrote: > > Thomas and Nicolas, thoughts? I think it would be good to eventually split the hostprog flags into 2 sets: the ones that are used for bootstrapping, and the ones that go after that. That way, we can get the best of both worlds, if I understand correctly. Cheers, Miguel
On Mon, Oct 06, 2025 at 01:27:33PM +0200, Miguel Ojeda wrote: > On Sun, Oct 5, 2025 at 10:53 PM Nathan Chancellor <nathan@kernel.org> wrote: > > > > Thomas and Nicolas, thoughts? > > I think it would be good to eventually split the hostprog flags into 2 > sets: the ones that are used for bootstrapping, and the ones that go > after that. > > That way, we can get the best of both worlds, if I understand correctly. Does that buy us much? We would not want -Werror applied to scripts/basic or scripts/kconfig without consent from the user. W=e could provide that at that stage of the build (with an adjustment of where scripts/Makefile.extrawarn was included) but CONFIG_WERROR would not be. Given how frequently fixdep and kconfig are built, I am fairly confident that new warnings wtihin them would be reported quickly, even without -Werror, so I do not see it as too much of a loss. All other host programs should be covered by that diff. It may still be worth doing for other reasons but I would have to see what such a change would actually look like in practice before committing to it. Cheers, Nathan
On Sun, Oct 05, 2025 at 01:53:35PM -0700, Nathan Chancellor wrote: (...) > In looking further into this, I noticed that in its current state, > -Werror is not getting applied to scripts/basic/fixup or > scripts/kconfig/*.o files (seems $(include-y) happens to late?), which > was one of the reasons to avoid making it depend on CONFIG_WERROR or > W=e. If that's the case, we could probably make it opt in like the rest > of the warnings for the kernel, which should be a fair compromise > between wanting to make potential issues more obvious while not > impacting people who build old sources with new compilers. > > Thomas and Nicolas, thoughts? Yeah, fixdep and script/kconfig seem to be specifically handled in the 'ifdef config-build' block in Makefile. And this happens explicitly before 'include .../auto.conf'. So your diff below looks like the correct solution. Thanks for taking a look! Thomas
I tried to make this argument recently for libbpf but was unsuccessful: https://lore.kernel.org/bpf/7e6c41e47c6a8ab73945e6aac319e0dd53337e1b.1751712192.git.sam@gentoo.org/ I agree, though.
On Thu, Aug 14, 2025 at 12:15 PM Thomas Weißschuh <thomas.weissschuh@linutronix.de> wrote: > > 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: Thomas Weißschuh <thomas.weissschuh@linutronix.de> > > --- > For testing in -next, as discussed in > https://lore.kernel.org/lkml/20250812-kbuild-werror-v1-2-36c9ff653700@linutronix.de/ The discussion was on patch 0, i.e. the next message in Lore's tree view -- I would suggest adding it to the commit message for reference: Link: https://lore.kernel.org/rust-for-linux/CANiq72k-PdSH2BNgbq=X+FhpyEErifSCKfO5ObXz6bu9_J8+fA@mail.gmail.com/ Anyway, since Nathan already applied it, and I see a couple patches on top, no big deal if it cannot be added. Thanks! Cheers, Miguel
On Sun, Aug 17, 2025 at 06:31:06PM +0200, Miguel Ojeda wrote: > The discussion was on patch 0, i.e. the next message in Lore's tree > view -- I would suggest adding it to the commit message for reference: > > Link: https://lore.kernel.org/rust-for-linux/CANiq72k-PdSH2BNgbq=X+FhpyEErifSCKfO5ObXz6bu9_J8+fA@mail.gmail.com/ > > Anyway, since Nathan already applied it, and I see a couple patches on > top, no big deal if it cannot be added. I dropped the top patch due to a build failure: https://lore.kernel.org/20250818140143.61b8c466@canb.auug.org.au/ So I was okay with just rebasing the top commit to amend this one, especially when giving more context to the patch. Thanks for the suggestion! Cheers, Nathan
On Thu, Aug 14, 2025 at 12:14:46PM +0200, Thomas Weißschuh wrote: > 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: Thomas Weißschuh <thomas.weissschuh@linutronix.de> > > --- > For testing in -next, as discussed in > https://lore.kernel.org/lkml/20250812-kbuild-werror-v1-2-36c9ff653700@linutronix.de/ yeah, I am not sure if this is a good change, but I am ok with testing it in next, as Nathan suggested. For the rest of the series: Reviewed-by: Nicolas Schier <nsc@kernel.org> Thanks. > --- > scripts/Makefile.extrawarn | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/scripts/Makefile.extrawarn b/scripts/Makefile.extrawarn > index 96ff3f5582d651f0016c8ccd49d46022cc6fe070..1434cb6208cb82f20aeb29cc8c059220d1a1f6d2 100644 > --- a/scripts/Makefile.extrawarn > +++ b/scripts/Makefile.extrawarn > @@ -224,3 +224,8 @@ KBUILD_USERLDFLAGS += -Wl,--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 > > -- > 2.50.1 >
On Thu, Aug 14, 2025 at 02:10:13PM +0200, Nicolas Schier wrote: > On Thu, Aug 14, 2025 at 12:14:46PM +0200, Thomas Weißschuh wrote: > > 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: Thomas Weißschuh <thomas.weissschuh@linutronix.de> > > > > --- > > For testing in -next, as discussed in > > https://lore.kernel.org/lkml/20250812-kbuild-werror-v1-2-36c9ff653700@linutronix.de/ > > yeah, I am not sure if this is a good change, but I am ok with testing > it in next, as Nathan suggested. Yeah, I will leave this as the top patch in kbuild-next for now so that we can easily back out if it is disruptive. > For the rest of the series: > > Reviewed-by: Nicolas Schier <nsc@kernel.org> I applied this tag to patches 1 through 5 and left it off of this one, based on "for the rest of the series". Let me know if that was unintentional. Cheers, Nathan
© 2016 - 2026 Red Hat, Inc.