On Mon, 5 Jan 2026 at 18:22, Paul Eggert <[email protected]> wrote: > > On 2026-01-05 10:12, Jonathan Wakely wrote: > > { > > // 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, > > Thanks for reporting this. I assume removing that first statement fixes > things. Although we could do that for Gnulib, in upstream Autoconf we > ran into that problem, removed the first statement here: > > https://cgit.git.savannah.gnu.org/cgit/autoconf.git/commit/?id=e6c9cb69c8c0a4ef9ce0538d7b4106dad3d7ad47 > > tried to adjust further to C++14 through C++23 here: > > https://cgit.git.savannah.gnu.org/cgit/autoconf.git/commit/?id=f6522328c71a62e3d182def319167ac15c8feaa5 > > but then decided that it's a fool's errand for 'configure' to change the > C++ version, so we changed things so that AC_PROG_CXX no longer does that: > > https://cgit.git.savannah.gnu.org/cgit/autoconf.git/commit/?id=056518b94ecd487bcbefdb69046b3f52c4168222
Ah, that explains why I didn't find the problem code in autoconf and only in gnulib. Maybe the packages failing to build in Fedora rawhide are actually using a configure script created by autoconf when it still had the buggy AC_PROG_CXX, and are nothing to do with gnulib. > I assume Gnulib should do likewise? Yes, I think so.
