[OE-core] [PATCH 2/2] glibc: Upgrade to 2.27 release

[Khem Raj]

glibc community thinks that the way we are depending upon old
localedata while using newer
glibc in nativesdk is not a supported usecase, and there is no
guarantees of internal data structures changes between major releases,
like what we are facing here. The suggestion is
to ship own localedata instead of relying on SDK host. You can follow
the discussion on glibc
thread I added in previous email and if have some suggestions or
inputs feel free.

I will try to come up with a patch along with this upgrade to add
nativesdk locale along and
check if this fixes the issue we have

On Sat, Feb 17, 2018 at 11:58 PM, Khem Raj <raj.khem at gmail.com> wrote:
> Wanted to send update on this issue
>
> I got to bottom of this issue and Ross you should have known it :)
>
> https://patchwork.openembedded.org/patch/127105/
>
> introduced an optimization into nativesdk glibc to let it ride on localedate
> from SDK host. This has now broken in glibc with
>
> https://github.com/kraj/glibc/commit/95cb863a1ef7760a11272bbd7ba5fe62dc41be54
>
> it is recommended for static programs to be relinked if using glibc 2.27
> our case is also similar mismatch of libc version and localedata just in
> opposite direction where we are trying to read old data with new glibc
> instead.
>
> I have initiated a discussion within glibc community on it to explore what
> options we have, but be prepared to ship full localedata in worst case with
> glibc 2.27,  this might be the worst case option if no alternative is found.
>
> Thank you
> -Khem
>
> On 2/15/18 4:12 AM, Burton, Ross wrote:
>>
>> Yes, that's it.
>>
>> Ross
>>
>> On 12 February 2018 at 07:32, Khem Raj <raj.khem at gmail.com
>> <mailto:raj.khem at gmail.com>> wrote:
>>
>>     On Sat, Feb 3, 2018 at 2:21 AM, Burton, Ross <ross.burton at intel.com
>>     <mailto:ross.burton at intel.com>> wrote:
>>     > Getting there: https://autobuilder.yocto.io/tgrid
>> <https://autobuilder.yocto.io/tgrid>
>>     >
>>     > Just two actual problems:
>>     > - The non-gplv3 build failed as the make fix needs to be backported
>> to
>>     > meta-gplv2
>>     > - The eSDK selftests all failed with en_US.UTF-8 problems, the new
>> glibc
>>     > shouldn't be causing a problem with uninative so this is
>> interesting, maybe
>>     > the new one is behaving slightly differently.  Should be easy to
>> replicate.
>>     > The same problem caused selftest to fail.
>>     >
>>
>>     is the UTF error like this one
>>     https://gist.github.com/25a84d23618824f0e5e6857a960eaca4
>>     <https://gist.github.com/25a84d23618824f0e5e6857a960eaca4>
>>
>>      > Ross
>>
>>
>