At Mon, 20 Oct 2025 11:18:32 +0200, "Dr. Thomas Orgis" <thomas.orgis%uni-hamburg.de@localhost> wrote:
Subject: Re: Fixing configure failures from newer gcc
>
> That's autoconf 2.72 from 2023. Seems like it is not really prepared
> for a newer standard _not_ being better for this codebase. So is this
> an autoconf bug? GCC defaults obsoleting the GNU build tooling …
There is ongoing work on Autoconf for C23 support, but no new release in
the last 22 months. It's still ugly though.
> Upstream fixing a standard could be undesired in that case. So, what is
> the fully correct way to behave for me as upstream? Of course I'd like
> to some way to specify that my code prefers a certain language standard
> and possibly could work with supersets of that … but without breaking
> other stuff downstream.
Personally I've dropped Autoconf. It always did too much, too often,
and with far too much complexity required in the code it configured,
even if one used it minimally.
Well written C code shouldn't need the full depths of Autoconf if it
targets any modern or even semi-modern systems, and any configuration
needed should be doable with Make variables and command-line settings
passed to the compiler.
My projects have rather narrow porting objectives so for me NetBSD Make,
with by Simon Gerraty's release (https://crufty.net/help/sjg/bmake.html)
used for non-NetBSD platforms, is sufficient. This avoids that horror
called libtool too. (Plain GNU Make doesn't have the richness of the
normal BSD Make "mk" files by default, and there isn't even any commonly
available distribution of GNUMakefile macros that could even approach
that richness either -- it's a non-starter -- I don't think it even has
the right attitude to approach the problem, thus things like automake).
I also only worry about using GCC and Clang, at least for now, though
anything reasonably compatible with them should work too. Some day I
hope PCC is usable as a NetBSD system compiler! Maybe someday Cproc can
work too!
Maybe what I do won't work for everyone. :-)
Anyway I just do the following (after ".include <bsd.prog.mk>"):
CSTD = c89
.if empty(CFLAGS:M*-std=${CSTD}*)
CFLAGS += -std=${CSTD}
.endif
That makes sure my "CSTD" is last on the command line unless an exact
match is already there, sort of like FORCE_C_STD works in pgksrc. I
have to make sure it is last, and after <bsd.prog.mk>, because some
variants of BSD Mk files add their own version without asking
(e.g. NetBSD before 10.0).
For a complete working example see https://github.com/robohack/fingerd
That's been tested with GCC up to GCC-15 and Clang up to Clang-19, and
note it's still even using K&R function declarations!
I have a few projects that are tested as C99 code, but I haven't updated
all their Makefile infrastructure to my latest scheme yet.
A sparse example is my BSD Makefile for CTWM: github.com/robohack/ctwm-mirror
(that works on NetBSD and should work on FreeBSD and maybe other BSDs)
(I wanted to test linux, but the box I had borrowed for some time didn't
end up having a viable enough development environment on it and I can't
bring myself to even install a Linux in a test VM.)
I don't see any value in trying to declare to a downstream consumer that
some project might be able to be compiled at a newer/higher language
level even though it's only tested at some lower level.
I think C23 is showing us that deep backward compatability for legacy
code is gone for good, and good riddance. However that means code can
no longer be expected to have future forward compatability either. If
it's tested at C99, then let's keep it there until it can be tested
further. So long as compilers continue to offer something like "-std="
to compile at older levels then there is no need to ride the bleeding
edge of the latest and greatest -- just stick firmly to the middle
ground and thus continue to also support older systems with older
compilers.
--
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:
pgpPlz2BgsMvG.pgp
Description: OpenPGP Digital Signature