Paul Eggert wrote in
<https://lists.gnu.org/archive/html/bug-gnulib/2024-07/msg00289.html>:
> +# Prefer GNU C23 to earlier versions.
This module does not have the intended effect: With a gcc 15 snapshot,
the 'configure' script of a gnulib testdir produces:
checking for /gnu-inst-gcc/15-20241113/bin/gcc option to enable C23 features...
unsupported
checking for /gnu-inst-gcc/15-20241113/bin/gcc option to enable C11 features...
none needed
I would have expected:
checking for /gnu-inst-gcc/15-20241113/bin/gcc option to enable C23 features...
-std=gnu23
This comes from this piece of code:
> +
> +#include <stdbit.h>
> +static_assert (__STDC_ENDIAN_LITTLE__ != __STDC_ENDIAN_BIG__);
> +
which (in config.log) leads to:
conftest.c:74:10: fatal error: stdbit.h: No such file or directory
74 | #include <stdbit.h>
| ^~~~~~~~~~
This test for <stdbit.h> is not useful, because <stdbit.h> is part of
the C library, not part of the compiler.
* It has the effect that even with the newest GCC and clang compilers,
the test "for ... option to enable C23 features" will say "unsupported"
on all glibc versions < 2.39 and on many other platforms.
* It does not consider the possibility that the package might not require
<stdbit.h> or might provide <stdbit.h> via the Gnulib module — since
by the time 'configure' runs, the Gnulib module has not been built yet.
I would suggest to remove this part of the C23 test. I mean, the test for C11
does not require <uchar.h> to be installed either.
Then, packages can make use of new C23 language features by requiring a
recent compiler on the target platform, but without requiring an entirely
recent OS with glibc on the target platform.
Bruno
