I've made it work! See the patches in poky-contrib:ross/glibc, although I'm cleaning them up now.
Ross On 23 February 2018 at 03:06, Khem Raj <raj.k...@gmail.com> wrote: > 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.k...@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/95cb863a1ef7760a11272bbd7ba5fe > 62dc41be54 > > > > 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.k...@gmail.com > >> <mailto:raj.k...@gmail.com>> wrote: > >> > >> On Sat, Feb 3, 2018 at 2:21 AM, Burton, Ross <ross.bur...@intel.com > >> <mailto:ross.bur...@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 > >> > >> > > >
-- _______________________________________________ Openembedded-core mailing list Openembeddedemail@example.com http://lists.openembedded.org/mailman/listinfo/openembedded-core