Re: [PATCH v12 0/6][BZ 10871] Month names in alternative grammatical case

[Rafal Luzynski <digitalfreak at lingonborough dot com>]

18.02.2018 08:50 Khem Raj <raj.khem@gmail.com> wrote:
>
> On 1/20/18 12:41 AM, Carlos O'Donell wrote:
> > On 01/14/2018 07:03 AM, Rafal Luzynski wrote:
> >> A workaround for the problem would be to deliver the old locale data
> >> and put their directory name in the LOCPATH environment variable.
> >>
> >> A similar problem has been reported as a bug 19084 [2] and the answer
> >> was that it cannot be fixed for statically linked binaries.
> >
> > OK, I have finished reviewing these patches again and testing some builds.
> >
> > I agree that today we cannot support statically linked applications using
> > new data.
> >
> > Florian Weimer fairly clearly stated that he didn't object to this.
> >
> > v12 + Rical's suggestions are good.
> >
> > Please commit v12 :-)
> >
>
> I am running into an interesting problem due to one of commits in this
> series
>
> https://github.com/kraj/glibc/commit/95cb863a1ef7760a11272bbd7ba5fe62dc41be54
>
> 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. So this optimization have worked well so far
> and we were able to run all SDKs on distros running glibc localedata as
> old as 2.15

Was 2.15 maybe the last time a new field has been added to glibc locale
data specification?

> [...]
> I know we can build full locale set and ship it along, but it increases
> SDK size so I want to know if we were just lucky thus far and it was
> not supposed to work with old locale data.
>
> What is recommended way forward ?

As it has been discussed in this thread (partially quoted above) I'm
afraid that there is no good solution for you.  If you can sacrifice
100+ MB and ship them with your SDK then it sounds good.  But, hey,
are you sure you need all locale data?  Maybe you can deliver only
a limited subset or make them available for download?

Alternatively you may think about relaxing the sanity tests in
locale/programs/ld-time.c and let them load the locale data having
the incomplete LC_TIME section.  But it's hard to say what happens
when an application uses strftime("%OB").  Will it crash?  You can
make one step further and undo whole patch which you have quoted.
If you do so and an application calls strftime("%OB") it will output
"%OB" as every other invalid specifier.  But would the users be
satisfied?  Especially if an application detects the glibc version
2.27 and expects "%OB" to be supported?

No solution sounds good to me.  I don't know what are the actual
needs of your users, maybe indeed delivering a limited subset of locales
is a good solution.

Or maybe indeed we should rethink the sanity tests and assume that
the optional fields are also optional in the binary locale data files
as long as they appear at the end of the file?

Best regards,

Rafal