public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/101234] New: Two tests require en_US.ISO-8859-15 but glibc no longer installs that by default.
@ 2021-06-28  1:50 zarniwhoop at ntlworld dot com
  2021-06-28  2:15 ` [Bug libstdc++/101234] " pinskia at gcc dot gnu.org
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: zarniwhoop at ntlworld dot com @ 2021-06-28  1:50 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101234

            Bug ID: 101234
           Summary: Two tests require en_US.ISO-8859-15 but glibc no
                    longer installs that by default.
           Product: gcc
           Version: 11.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: zarniwhoop at ntlworld dot com
  Target Milestone: ---

In 22_locale/codecvt/out/wchar_t/3.cc and 22_locale/codecvt/in/wchar_t/3.cc the
tests are only run if dejagnu finds the en_US.ISO-8859-15 locale. I assume that
glibc used to install that when installing all locales (e.g.
[https://centos.pkgs.org/8-stream/centos-baseos-x86_64/glibc-langpack-en-2.28-155.el8.x86_64.rpm.html]
implies that), but recent glibc does not automatically install it.

My earliest available old system is using glibc-2.30 and there that locale was
not installed when I installed all locales.

Manually installing it on a current system with glibc-2.33, the number of
expected passes increased by 4 so the tests do still work, it is just that most
builders will not run them.

If I'm reading the tests correctly, they convert the whole character-set.
Perhaps they could be converted to use one of the @euro locales which are still
installed automatically by glibc ?  I see that at least de_DE@euro and
es_ES@euro are in that category and alreadty used by other tests.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug libstdc++/101234] Two tests require en_US.ISO-8859-15 but glibc no longer installs that by default.
  2021-06-28  1:50 [Bug libstdc++/101234] New: Two tests require en_US.ISO-8859-15 but glibc no longer installs that by default zarniwhoop at ntlworld dot com
@ 2021-06-28  2:15 ` pinskia at gcc dot gnu.org
  2021-06-28  8:02 ` harald at gigawatt dot nl
  2021-06-28  9:18 ` redi at gcc dot gnu.org
  2 siblings, 0 replies; 4+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-06-28  2:15 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101234

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Looks like the testsuite is incorrect, it should have been 'en_US.ISO8859-15'

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug libstdc++/101234] Two tests require en_US.ISO-8859-15 but glibc no longer installs that by default.
  2021-06-28  1:50 [Bug libstdc++/101234] New: Two tests require en_US.ISO-8859-15 but glibc no longer installs that by default zarniwhoop at ntlworld dot com
  2021-06-28  2:15 ` [Bug libstdc++/101234] " pinskia at gcc dot gnu.org
@ 2021-06-28  8:02 ` harald at gigawatt dot nl
  2021-06-28  9:18 ` redi at gcc dot gnu.org
  2 siblings, 0 replies; 4+ messages in thread
From: harald at gigawatt dot nl @ 2021-06-28  8:02 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101234

Harald van Dijk <harald at gigawatt dot nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |harald at gigawatt dot nl

--- Comment #2 from Harald van Dijk <harald at gigawatt dot nl> ---
(In reply to Ken Moffat from comment #0)
> In 22_locale/codecvt/out/wchar_t/3.cc and 22_locale/codecvt/in/wchar_t/3.cc
> the tests are only run if dejagnu finds the en_US.ISO-8859-15 locale. I
> assume that glibc used to install that when installing all locales (e.g.
> [https://centos.pkgs.org/8-stream/centos-baseos-x86_64/glibc-langpack-en-2.
> 28-155.el8.x86_64.rpm.html] implies that), but recent glibc does not
> automatically install it.

This locale was and is a Red Hat change, not something that used to be part of
official glibc:
<https://src.fedoraproject.org/rpms/glibc/blob/rawhide/f/glibc-fedora-localedata-rh61908.patch>.
This patch is still used by Red Hat now.

(Not that that means the test should continue using this locale.)

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug libstdc++/101234] Two tests require en_US.ISO-8859-15 but glibc no longer installs that by default.
  2021-06-28  1:50 [Bug libstdc++/101234] New: Two tests require en_US.ISO-8859-15 but glibc no longer installs that by default zarniwhoop at ntlworld dot com
  2021-06-28  2:15 ` [Bug libstdc++/101234] " pinskia at gcc dot gnu.org
  2021-06-28  8:02 ` harald at gigawatt dot nl
@ 2021-06-28  9:18 ` redi at gcc dot gnu.org
  2 siblings, 0 replies; 4+ messages in thread
From: redi at gcc dot gnu.org @ 2021-06-28  9:18 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101234

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #1)
> Looks like the testsuite is incorrect, it should have been 'en_US.ISO8859-15'

I think that's exactly equivalent, the extra dash is optional.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2021-06-28  9:18 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-28  1:50 [Bug libstdc++/101234] New: Two tests require en_US.ISO-8859-15 but glibc no longer installs that by default zarniwhoop at ntlworld dot com
2021-06-28  2:15 ` [Bug libstdc++/101234] " pinskia at gcc dot gnu.org
2021-06-28  8:02 ` harald at gigawatt dot nl
2021-06-28  9:18 ` redi at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).