At Sat, 15 Jun 2024 19:07:17 -0400, Greg Troxel <gdt%lexort.com@localhost> wrote:
Subject: Re: dealing with inevitable warnings from new compilers on old code
>
> I am unclear on how far back we can go and cope.
As far back as current compilers allow! :-)
For Clang up to Clang-16.x that means ISO C 1990 (or gnu90) (they equate
c89 with c90 but separate out iso9899:199409).
For GCC up to GCC-14.x I think that also means ISO C 1990 (or gnu90),
And we do need to go back gnu90 often enough with Clang-15.x!
> > it's not likely necessary to ever have to combine USE_CC_FEATURES (as it
> > is currently implemented) and FORCE_C_STD to downgrade the language
> > level, though obviously there isn't any harm in it either, and I guess
> > it could be updated to catch out any compiler that had dropped support
> > for legacy language levels.
>
> You are assuming that FORCE_{C,CXX} are downgrade.
No that's not assuming that's what FORCE_C*_STD are for, but rather I am
simply wanting to use them to be able to do that when necessary.
BTW, one more point I've found in many Autoconf (+Automake) configure
scripts:
Typically packages will use AC_PROG_CC alone to find a C compiler, and
that will do a test like:
checking for gcc option to accept ISO C89... none needed
However that is of course insufficient as it only does a minimal test.
Packages often won't compile any more with Clang-15.x and will actually
need '-std=c90' (or '-std=gnu90' as appropriate). Even gnu99 causes
Clang to find fatal errors.
One example is textproc/xmlto (as of xmlto-0.0.28).
> But it is important to be clear about
> what is buggy and what is not.
100% agreed!
> > Ideally there could be a (mostly internal) "DEFAULT_C_STD" setting too
> > (i.e. not for use in individual package Makefiles), which would be
> > automatically chosen based on the current platform's default compiler
> > and some overall assessment of the state of legacy code in all packages.
>
> I don't think that's ideal; I think it would cause more trouble than it
> is worth. Adding FORCE_*_STD is not that hard, and it doesn't happen
> all that often.
I'm OK with that -- I just don't necessarily want to be the first one to
trip over all those packages that do need it though, especially as I
don't have commit access to quickly fix them. Someone with commit
access, and who is regularly doing full bulk builds of all (or as much as
possible) of pkgsrc, could obviously do it though.
I was very nearly ready to try rebuilding the set of packages I use on
macos when Amitai posted in April. Since then I've held off. I did not
fully appreciate how FORCE_C*_STD could be used at that time else I
might not have been scared off. I do have both a FreeBSD-14 VM (or
more), as well as my macos (x86 14.x) desktop to work with, but I don't
build a very large set of packages (~850 or so on the desktop at the
moment).
Note though that what Amitai did with his -Wno-error hacks was the more
or less the equivalent of setting a default FORCE_C_STD=gnu90, so as yet
we don't really know what level of breakage there might be. As his
comments say:
# As soon as 2024Q1 branches, we should:
#
# 1. Do a bulk build with all these -Wno-error tweaks removed, so we can
# see how much is broken.
# 2. If it's "too much" breakage and we'll have to keep overriding these
# compiler defaults for "a while", find a way to accomplish them with
# fewer compiler invocations. (Some ideas: define a default
# FORCE_C_STD, or apply overrides keyed on CC_VERSION or similar.) Do
# a bulk build to make sure things continue to work as before.
# 3. Otherwise, fix as much as we can before 2024Q2. This will help with
# gcc 14 (which has many similar new defaults) as well.
--
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:
pgpQZiEO1rEHB.pgp
Description: OpenPGP Digital Signature