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
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Reply via email to