At Sat, 11 Oct 2025 09:00:24 -0400, Greg Troxel <gdt%lexort.com@localhost> wrote: Subject: Re: Fixing configure failures from newer gcc > > The proper thing is to figure out if the warnings are valid or not, and > either fix upstream or gcc. The warnings and errors are entirely valid, and neither GCC nor Clang are wrong to issue them _by default_. However it may not be appropriate/worthwhile to fix these problems yet, and especially not to go pushing such fixes upstream, yet. > I think it's broken to have -Werror in configure, unless both upstream That's really an entirely separate issue, though it does exacerbate the underlying problem. > It's also possible that gcc14 is defaulting to some new c std, and this > program simply isn't in that standard. Exactly -- that is _entirely_ the issue. Modern compilers default to expecting that the code they are compiling is written to whatever language standards level is/was current for that version of the compiler, and of course newer C standards are actually not fully backward compatible with previous versions. > I think that's also broken of > gcc; programs that want c23 should ask for it. Well, OK, but... Modern compilers and their maintainers want them to default to the current and/or best-supported and most current language level, so that's what they do -- you can tilt at the windmills of change, or accept it. It is actually more "our" fault for assuming "cc" (or "gcc", or "clang") are NOT moving targets -- if we upgrade the compiler we should expect it to do new things. Yes, programs should specify their language level to the compiler, but that also hasn't happened yet, and since modern gcc (and clang) have gone ahead and decided that c23 is the default, _we_ have to be explicit about telling them to "BACK OFF!" when compiling legacy code. We are only just now entering the era of new language levels that are not fully backward compatible. So far, with current GCC and Clang at least, specifying "-std=NN" will disable the new required warnings and errors, and of course it will also force the compiler to treat the code the same way the earlier compilers did. > So a good question is > "what std is this program in", and then configure should be checking for > and setting that. Maybe that is happening, maybe not, and it might or > might not be relevant. Possibly it would have been a good idea for _everyone_ to have continued using the old "c89" or "c99" wrapper front-ends (i.e. instead of "cc") that made it most explicit what language level one was expecting and getting, but the world chose a different way to go. Or maybe there should have been a "#pragma STD NN" that all code should have included. All that is water under the bridge. Anyway, I don't think it is relevant whether or not a package's configure script is doing the right thing or not. All that matters is if there are errors or not, and if there then always force "-std=c89" (or whatever is appropriate for the code in question). I.e. tell the compiler to back off and treat the old code properly and you won't have to try to figure out all the myriad of ways to try to turn off the new errors _required_ by more recent language standards levels. There is the risk that legacy code which doesn't get "-std=c89", and which doesn't trigger any new warnings or errors will still encounter new UB at runtime, but maybe that's quite rare. Maybe it's worthwhile pushing upstream maintainers to add "-std=c99", but perhaps it's not worth the bother. Choosing to use a newer compiler is the user's/our choice, and so we need to figure out how to use these newer compilers properly for legacy code and if/when the upstream maintainer eventually does the same, well then they can figure out whether to just continue telling the compilers to back off, or whether they want to fix their code and possibly force everyone who uses it to upgrade their compiler. > Thus, your idea of "if gcc and gcc>=14 add these flags" is basically the > right approach, No, that's the wrong fix, no matter what version of compiler you use. The _ONLY_ right fix is to tell the compiler what language level the code being compiled is written to. Just use "-std-c99". Don't try to figure out what -Wno-* flags are needed -- that's a compiler-specific game of whack-a-mole that just wastes time and hides the real problem. The only other concern is when building something that's clearly written for a newer language level than the default older compiler on some platform supports, but that's when you want to have pkgsrc install and use a newer compiler as a build requirement. I think the framework to make this choice may still need some fixing though -- it should only be about the required language standard level, and about which level the platform default compiler supports, not which specific version of which compiler is needed. Then choice about which compiler to install to support a higher standard level should, by default, be whichever one is supported on, and most easily and/or reliably used on, the target platform. > if patching on -Werror isnt' ok. FYI that's not actually going to work on the most modern versions of GCC and Clang. There is a magic "-Wno-everything" (for both GCC and Clang), but that's still not the correct solution -- just use "-std=c89" (or "-std=c99", etc.)!!! There are many (most?) packages which don't explicitly pass "-std=cNN" as necessary, and they should probably be patched, but the quicker work-around is to have a wrapper script which inserts "-std=c99" if there's no other "-std=" option already given (note C99 is likely going to work as a first guess as we've been blindly assuming most code is ready for C99 for a while now, and indeed C99 is/was more or less truly backward-compatible with C89). -- Greg A. Woods <gwoods%acm.org@localhost> Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost> Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgpV5XoGE2SUC.pgp
Description: OpenPGP Digital Signature