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

Khem Raj raj.khem at gmail.com
Fri Feb 23 14:45:10 UTC 2018


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/95cb863a1ef7760a11272bbd7ba5fe62dc41be54
>> >
>> > 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
>> >>
>> >>
>> >
>
>



More information about the Openembedded-core mailing list