This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v12 0/6][BZ 10871] Month names in alternative grammatical case
- From: Khem Raj <raj dot khem at gmail dot com>
- To: Carlos O'Donell <carlos at redhat dot com>, libc-alpha at sourceware dot org
- Date: Wed, 21 Feb 2018 21:25:04 -0800
- Subject: Re: [PATCH v12 0/6][BZ 10871] Month names in alternative grammatical case
- Authentication-results: sourceware.org; auth=none
- References: <1802414843.37687.1515744747279@poczta.nazwa.pl> <1619e294-a9db-cebe-11c1-ce6a05b7ffd5@redhat.com> <1503957542.92463.1515942210174@poczta.nazwa.pl> <ce46d450-e814-677b-0c8e-0a26ea246335@redhat.com> <e8c811d7-519a-24c9-bbf1-99dadf29317d@gmail.com> <10bc0aed-9a97-3d8d-da52-845185941a6b@redhat.com>
Hi Carlos
On 2/21/18 8:30 PM, Carlos O'Donell wrote:
On 02/17/2018 11:50 PM, Khem Raj wrote:
In OpenEmbedded SDKs a glibc for SDK host is built along for some of
the native SDK to run uniformly across mutliple distributions. This
glibc is built with complocaledir=/usr/lib/locale in configparms
so that it can use the locales from the SDK host and we dont have to
ship 100+ Mb of localedata.
What you are doing is unsupported and relying on internal implementation
details not to change.
understood that all along, was trying out my luck if there was any
better solution, with the arrangements we had, we did not have to worry
about what locale the end user was using.
Each new version of glibc is tied to the binary locale data that it produces
and the same problem applies to static applications which will need to fall
back on C/POSIX locales because they will be unable to load the newer
format of locale data.
What is recommended way forward ?
Provide a minimal locale-archive with just the languages you support, and
that should only be ~3MiB per language.
We never set a limit here, but I guess we now need to.
Thank you
-Khem