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

[Burton, Ross]

Yep, overriding it for nativesdk now (and will propose we change the
default later)

On 23 February 2018 at 14:45, Khem Raj <raj.khem at gmail.com> wrote:

> On Fri, Feb 23, 2018 at 4:29 AM, Burton, Ross <ross.burton at intel.com>
> wrote:
> > I've made it work!  See the patches in poky-contrib:ross/glibc, although
> I'm
> > cleaning them up now.
> >
>
>
> LOCALE_UTF8_IS_DEFAULT setting is in conf/distro/include/default-
> distrovars.inc
>
> > Ross
> >
> > On 23 February 2018 at 03:06, Khem Raj <raj.khem at 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.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/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.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
> >> >>
> >> >>
> >> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20180223/449683c0/attachment-0002.html>