<div dir="ltr">Yep, overriding it for nativesdk now (and will propose we change the default later)</div><div class="gmail_extra"><br><div class="gmail_quote">On 23 February 2018 at 14:45, 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"><span class="">On Fri, Feb 23, 2018 at 4:29 AM, Burton, Ross <<a href="mailto:ross.burton@intel.com">ross.burton@intel.com</a>> wrote:<br>
> I've made it work! See the patches in poky-contrib:ross/glibc, although I'm<br>
> cleaning them up now.<br>
><br>
<br>
<br>
</span>LOCALE_UTF8_IS_DEFAULT setting is in conf/distro/include/default-<wbr>distrovars.inc<br>
<div class="HOEnZb"><div class="h5"><br>
> Ross<br>
><br>
> On 23 February 2018 at 03:06, Khem Raj <<a href="mailto:raj.khem@gmail.com">raj.khem@gmail.com</a>> wrote:<br>
>><br>
>> 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>
>><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<br>
>> > localedate<br>
>> > from SDK host. This has now broken in glibc with<br>
>> ><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<br>
>> > what<br>
>> > options we have, but be prepared to ship full localedata in worst case<br>
>> > with<br>
>> > glibc 2.27, this might be the worst case option if no alternative is<br>
>> > 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<br>
>> >> backported<br>
>> >> to<br>
>> >> > meta-gplv2<br>
>> >> > - The eSDK selftests all failed with en_US.UTF-8 problems, the<br>
>> >> 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>
><br>
><br>
</div></div></blockquote></div><br></div>