This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Consensus: Locale format may change from release to release?
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Allan McRae <allan at archlinux dot org>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 28 Oct 2015 01:44:43 -0400
- Subject: Re: Consensus: Locale format may change from release to release?
- Authentication-results: sourceware.org; auth=none
- References: <56185EE7 dot 5040106 at redhat dot com> <561B198D dot 4090800 at archlinux dot org> <561D0F2F dot 7070303 at redhat dot com> <20151024042932 dot GR26317 at vapier dot lan>
On 10/24/2015 12:29 AM, Mike Frysinger wrote:
> On 13 Oct 2015 10:03, Carlos O'Donell wrote:
>> I suggest we make a "Best Practices for upgrading glibc" document that
>> starts like this:
>
> so this direction seems to miss an edge case: static binaries. if locale
> data is incompatible, and we abort when trying to load incompatible data,
> then static binaries cannot safely use any locale functions.
I don't think we want to abort. We want to fail with NULL/EINVAL.
We want to assure people that if you upgrade your static apps will
work but they might just fall back to C/POSIX builtin locale. Maybe
another reason to get C.UTF-8 into builtin instead of external.
c.