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

[Khem Raj <raj dot khem at gmail dot com>]

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
however, after this commit this is no longer working a simple program

like

#include <locale.h>
#include <stdio.h>
#include <time.h>

int main () {

   printf("Locale is: %s\n", setlocale(LC_ALL, "en_US.UTF-8"));

   return(0);
}

compiled like

gcc a.c -Wl,-rpath,/tmp/glibc -g3 -O0 && 
LD_PRELOAD=/tmp/glibc/lib/libc.so.6 ./a.out

will show that its not able to read /usr/lib/locale/locale-archive from 
system

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 ?

Thank you
-Khem