On Mon, 5 Jan 2026 at 16:14, Jonathan Wakely <[email protected]> wrote:
>
> The gnulib autoconf checks for C++11 support include this code:
>
> {
> // Unicode literals
> char const *utf8 = u8"UTF-8 string \u2500";
> char16_t const *utf16 = u"UTF-8 string \u2500";
> char32_t const *utf32 = U"UTF-32 string \u2500";
> }
>
> That first statement is not valid in C++20, because the type of
> u8"str" literals changed to const char8_t[] instead of const char[].
>
> GCC 16 now defaults to -std=gnu++20, which means that configure
> scripts using gnulib decide that GCC 16 does not support C++11
> features unless you use the -std=gnu++11 option. This is ... kinda
> true. It doesn't support that *exact* feature. But it does support u8
> literals, and all the other C++11 features checked for under "C++11
> support".
>
> This bug causes some packages to fail to build with GCC 16, because
> the "do we need an option for C++11 support?" check decide yes, and
> that adds an explicit -std=gnu++11 option, which then causes the
> package to fail if it actually relies on anything from C++14 or later.
> Specifically, Google's Abseil library now requires at least C++17,
> which should be fine for GCC 16 which defaults to C++20. But all
> packages that use this gnulib configure check now add an explicit
> -std=gnu++11 option, and so fail to compile if they use any Abseil
> code.
You could solve it like this:
--- a/m4/std-gnu11.m4
+++ b/m4/std-gnu11.m4
@@ -777,7 +777,7 @@ AC_DEFUN([_AC_CXX_CXX11_TEST_BODY],
}
{
// Unicode literals
- char const *utf8 = u8"UTF-8 string \u2500";
+ auto const *utf8 = u8"UTF-8 string \u2500";
char16_t const *utf16 = u"UTF-8 string \u2500";
char32_t const *utf32 = U"UTF-32 string \u2500";
}
This uses another C++11 feature to make the code agnostic to the exact
type of u8"" so that it compiles for C++11 and later versions.
