At 18 Mar 2024 10:38:32 -0400, "Amitai Schleier" <schmonz%schmonz.com@localhost> wrote: Subject: Re: macOS clang has enabled -Werror=implicit-int > > On 17 Mar 2024, at 14:53, Greg A. Woods wrote: > > > Have you tried using "-std=c90" (or "-std=gnu90")? It works for me in > > all the cases I've had to deal with so far. > > Can you say more about how to apply this > idea in the current context? My > imagination is limited to either > explicitly setting the equivalent of > USE_CC_FEATURES=c90 in each package that > seems to need it, or else making that the > default language level. Neither of these > seems likely to meet all three criteria on > my mind at the moment: > > 1. "Fixes" for the moment whatever the new compiler defaults would break > 2. Doesn't cause anything new to break for anyone else > 3. Is conservative and effective late in > the quarter, heading into a freeze for the > next stable branch I _think_ a _default_ of "gnu99" pkgsrc-wide should cover all three of those concerns almost completely(*). (I now think "gnu90", and esp. "c90", are probably too pessimistic.) That's effectively what we've been doing with previous compiler versions given their default modes, especially with respect to which warnings are triggering errors. (also note that for packages using BSD Make, and NetBSD code itself, that's actually what currently really happens -- see <bsd.sys.mk>) I'm actually not quite sure how this should be done in pkgsrc today. USE_CC_FEATURES is not yet fully implemented as far as I can see. It seems entirely lacking for Clang still (there's no support for setting _C_STD_FLAG.xxx at all for Clang, and for gcc it only seems to set GCC_REQD, and not also set "-std=" -- the latter is still reliant on the apparently "deprecated" uses of USE_LANGUAGES!). Probably the only thing as-is that would work lots of extra effort would be to change the default of USE_LANGUAGES from "c" to "gnu99". In theory that won't affect any packages that already set USE_LANGUAGES more carefully. Ultimately USE_CC_FEATURES should be fully implemented! In any case I think it's still rather rare for existing packages to already _require_ a newer compiler and language standard. Those that do can eventually set USE_CC_FEATURES to the minimum newer standard they are compatible with. There may actually still be a few packages that would be better off eventually setting USE_CC_FEATURES back to gnu89, but probably not many. (*) I don't currently have my macos box in shape to (re)build packages again since its recent upgrades, though I should try to get it working very soon now, so I haven't properly tested this on more than one or two manual test cases. The problem is we've forced a new compiler on existing code, i.e. code that was written and tested for older compilers implementing older versions of the language standard. Upgrading to a compiler that forcibly implements a new version of the language standard is always going to require some porting effort for most existing code. Many times new compilers are expected to be backwards compatible, but sometimes they have to be convinced to be so. This isn't as drastic as when systems introduced ANSI compilers and all the old code was still K&R, especially when warnings turned into errors, but I do think jumping on C17/gnu17, especially with an increasing number of warnings turned into errors, and with new errors, it might be getting close to that drastic though. I note that src/external/gpl3/gcc/README.warnings has lots of good notes about specific new warnings and other changes that can cause problems for NetBSD code itself. Oddly it doesn't mention how some warnings are actually becoming errors by default. At least now we have compilers that can be "downgraded" with a command-line option! -- 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:
pgpjy2NcGYkow.pgp
Description: OpenPGP Digital Signature