Re: Fixing configure failures from newer gcc

["Dr. Thomas Orgis" <thomas.orgis%uni-hamburg.de@localhost>]

Am Sat, 18 Oct 2025 19:33:22 -0400
schrieb Greg Troxel <gdt%lexort.com@localhost>:

> I stand by my statement that a program written in CNN should, as part
> of its configure (or whatever) probe for and add --std=cNN to CFLAGS,
> whether NN is old, normal, or new.

As an upstream with a C99 project, I used to have AC_PROG_CC_C99 (or
similar) in configure.ac and assumed that this communicates that I want
a compiler in C99 mode, however that mode is achieved (be it as default
or by some other obscure option than -std=c99) … as upstream author, I
explicitly wanted to abtain from assuming that the compile accepts
certain options.

As the _C99 macro(s) has been deprecated in autotools, just assuming
that compilers support c99 … I'm right now not sure what I am supposed
to do to ensure that my code is compiled in C99 mode, without assuming
something about the compiler used downstream. Maybe -std=c99 is
universal enough nowadays that there is no compiler left that doesn't
understand it. But is it my job to decide that? I thought that's
autoconf's job (or whatever build systems'), abstracting the toolchain.

Maybe it's obvious with checking updated documentation, but it may be
good to have it repeated here in the discussion: What is the canonical
way for an autotools project to indicate the exact language standard it
uses for C?

I read about AC_PROG_CC:

	If necessary, options are added to CC to enable support for ISO
	Standard C features with extensions, preferring the newest
	edition of the C standard for which detection is supported.
	Currently the newest edition Autoconf knows how to detect
	support for is C11, as there is little reason to prefer C17 to
	C11, and C23 is still too new. After calling this macro you can
	check whether the C compiler has been set to accept standard C
	by inspecting the shell variable ac_prog_cc_stdc. Its value
	will be ‘c11’, ‘c99’, or ‘c89’, respectively, if the C compiler
	has been set to use the 2011, 1999, or 1990 edition of the C
	standard, and ‘no’ if the compiler does not support compiling
	standard C at all. 

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 …

Also, I am reminded of the C++11 ABI breakage … it's not just language
standard, but sometimes you have to build code with a differing
standard than it expects just to match the ABI of other packages.

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.


Alrighty then,

Thomas

-- 
Dr. Thomas Orgis
HPC @ Universität Hamburg