https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71641
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
URL| |https://sourceware.org/bugz
| |illa/show_bug.cgi?id=23164
Resolution|--- |DUPLICATE
--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
There are two different issues causing this test to fail. It consistently fails
on gcc20 in the compiler farm, even with dynamic linking, which might be the
case for hppa-linux too.
On gcc20 it fails because errorstate == failbit, which happens because the
D_FMT string does not match what the testcase expects.
On my Fedora system D_FMT for the zh_TW locale is "西元%Y年%m月%d日" but on gcc20
(Debian 7.11) it's "%Y年%m月%d日".
The static linking case depends on whether libc is linked statically or not,
because it doesn't fail with -static-libstdc++, so this is the same as
https://sourceware.org/bugzilla/show_bug.cgi?id=23164 (and so a duplicate of PR
85732).
Here's my simplified C testcase:
#define _GNU_SOURCE
#include <locale.h>
#include <langinfo.h>
#include <stdio.h>
int main()
{
locale_t loc = newlocale(1 << LC_ALL, "zh_TW.UTF-8", 0);
const char* dfmt = nl_langinfo_l(D_FMT, loc);
printf("date format: %s\n", dfmt);
while (*dfmt)
printf("\\x%x", (unsigned char)*dfmt++);
printf("\n");
return 0;
}
On Fedora 27 (glibc 2.26) this prints:
date format: 西元%Y年%m月%d日
\xe8\xa5\xbf\xe5\x85\x83\x25\x59\xe5\xb9\xb4\x25\x6d\xe6\x9c\x88\x25\x64\xe6\x97\xa5
On Debian 7.11 (glibc 2.13) this prints:
date format: %Y年%m月%d日
\x25\x59\xe5\xb9\xb4\x25\x6d\xe6\x9c\x88\x25\x64\xe6\x97\xa5
And on either system with static linking it fails to find the locale data:
date format: %m/%d/%y
\x25\x6d\x2f\x25\x64\x2f\x25\x79
So this is not a libstdc++ bug, it's a glibc bug. Debian's glibc 2.13 has bad
locale data for zh_TW, and all versions of glibc have the static linking bug.
*** This bug has been marked as a duplicate of bug 85732 ***
