<div dir="ltr">I've made it work! See the patches in poky-contrib:ross/glibc, although I'm cleaning them up now.<div><br></div><div>Ross</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 23 February 2018 at 03:06, Khem Raj <span dir="ltr"><<a href="mailto:raj.khem@gmail.com" target="_blank">raj.khem@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">glibc community thinks that the way we are depending upon old<br>
localedata while using newer<br>
glibc in nativesdk is not a supported usecase, and there is no<br>
guarantees of internal data structures changes between major releases,<br>
like what we are facing here. The suggestion is<br>
to ship own localedata instead of relying on SDK host. You can follow<br>
the discussion on glibc<br>
thread I added in previous email and if have some suggestions or<br>
inputs feel free.<br>
<br>
I will try to come up with a patch along with this upgrade to add<br>
nativesdk locale along and<br>
check if this fixes the issue we have<br>
<div class="HOEnZb"><div class="h5"><br>
On Sat, Feb 17, 2018 at 11:58 PM, Khem Raj <<a href="mailto:raj.khem@gmail.com">raj.khem@gmail.com</a>> wrote:<br>
> Wanted to send update on this issue<br>
><br>
> I got to bottom of this issue and Ross you should have known it :)<br>
><br>
> <a href="https://patchwork.openembedded.org/patch/127105/" rel="noreferrer" target="_blank">https://patchwork.<wbr>openembedded.org/patch/127105/</a><br>
><br>
> introduced an optimization into nativesdk glibc to let it ride on localedate<br>
> from SDK host. This has now broken in glibc with<br>
><br>
> <a href="https://github.com/kraj/glibc/commit/95cb863a1ef7760a11272bbd7ba5fe62dc41be54" rel="noreferrer" target="_blank">https://github.com/kraj/glibc/<wbr>commit/<wbr>95cb863a1ef7760a11272bbd7ba5fe<wbr>62dc41be54</a><br>
><br>
> it is recommended for static programs to be relinked if using glibc 2.27<br>
> our case is also similar mismatch of libc version and localedata just in<br>
> opposite direction where we are trying to read old data with new glibc<br>
> instead.<br>
><br>
> I have initiated a discussion within glibc community on it to explore what<br>
> options we have, but be prepared to ship full localedata in worst case with<br>
> glibc 2.27, this might be the worst case option if no alternative is found.<br>
><br>
> Thank you<br>
> -Khem<br>
><br>
> On 2/15/18 4:12 AM, Burton, Ross wrote:<br>
>><br>
>> Yes, that's it.<br>
>><br>
>> Ross<br>
>><br>
>> On 12 February 2018 at 07:32, Khem Raj <<a href="mailto:raj.khem@gmail.com">raj.khem@gmail.com</a><br>
>> <mailto:<a href="mailto:raj.khem@gmail.com">raj.khem@gmail.com</a>>> wrote:<br>
>><br>
>> On Sat, Feb 3, 2018 at 2:21 AM, Burton, Ross <<a href="mailto:ross.burton@intel.com">ross.burton@intel.com</a><br>
>> <mailto:<a href="mailto:ross.burton@intel.com">ross.burton@intel.com</a>><wbr>> wrote:<br>
>> > Getting there: <a href="https://autobuilder.yocto.io/tgrid" rel="noreferrer" target="_blank">https://autobuilder.yocto.io/<wbr>tgrid</a><br>
>> <<a href="https://autobuilder.yocto.io/tgrid" rel="noreferrer" target="_blank">https://autobuilder.yocto.io/<wbr>tgrid</a>><br>
>> ><br>
>> > Just two actual problems:<br>
>> > - The non-gplv3 build failed as the make fix needs to be backported<br>
>> to<br>
>> > meta-gplv2<br>
>> > - The eSDK selftests all failed with en_US.UTF-8 problems, the new<br>
>> glibc<br>
>> > shouldn't be causing a problem with uninative so this is<br>
>> interesting, maybe<br>
>> > the new one is behaving slightly differently. Should be easy to<br>
>> replicate.<br>
>> > The same problem caused selftest to fail.<br>
>> ><br>
>><br>
>> is the UTF error like this one<br>
>> <a href="https://gist.github.com/25a84d23618824f0e5e6857a960eaca4" rel="noreferrer" target="_blank">https://gist.github.com/<wbr>25a84d23618824f0e5e6857a960eac<wbr>a4</a><br>
>> <<a href="https://gist.github.com/25a84d23618824f0e5e6857a960eaca4" rel="noreferrer" target="_blank">https://gist.github.com/<wbr>25a84d23618824f0e5e6857a960eac<wbr>a4</a>><br>
>><br>
>> > Ross<br>
>><br>
>><br>
><br>
</div></div></blockquote></div><br></div>