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.
