Am Thu, Dec 22, 2022 at 01:57:37AM +0100 schrieb Jeremie Courreges-Anglas: > On Thu, Dec 22 2022, Theo Buehler <t...@openbsd.org> wrote: > > On Thu, Dec 22, 2022 at 11:39:41AM +1100, Jonathan Gray wrote: > >> On Thu, Dec 22, 2022 at 01:20:32AM +0100, Theo Buehler wrote: > >> > > Any concerns regarding the changes in libz? It introduces diff to > >> > > upstream, but the recent commits seemed to indicate we have forked > >> > > anyway? > >> > > >> > I've worked hard to keep the diff to upstream minimal. Why are these > >> > changes needed? > >> > >> the warnings are from -Wdeprecated-non-prototype > >> > >> https://github.com/madler/zlib/issues/633 > > > > So, can't we fix this by adding -Wno-deprecated-non-prototype to the > > kernel build and wait until madler converts upstream? > > That's what I initially proposed on my own wip branch: > > > https://github.com/jcourreges/openbsd-src/commit/50d8bd24dadc25aa7e985de898bccf92a60b72ee > > -Wno-deprecated-non-prototype + -Wno-unknown-warning-option (the latter > option because current clang doesn't understand the former). libz built > as part of libsa and the bootloaders also needs a similar tweak in MD > Makefiles: > > > https://github.com/jcourreges/openbsd-src/commit/2107b762420ef6ea863e349e5faea4254d44fdf9 > > The build of src/lib/libz doesn't use -Werror and thus doesn't error out. > > The two commits above are obviously incomplete, other archs need similar > handling. Apart from the fact that I authored them, I think they're > the sanest way to handle this libz "oddness". Not just because I care > about tb's sanity. :)
I had hoped that we can resolve that without adding another set of -W flags everywhere, but I guess the libz churn isn't worth it. But yeah, maybe we'll just flip the default option in LLVM and then we'll just not use that warning... at all?
