Re: [PATCH 1/1] bitbake.conf: change localedir

["Radzykewycz, T (Radzy)" <radzy@windriver.com>]

________________________________________
> From: openembedded-core-bounces@lists.openembedded.org [openembedded-core-bounces@lists.openembedded.org] on behalf of Mark Hatle [mark.hatle@windriver.com]
> Sent: Friday, August 12, 2016 6:50 AM
> To: Khem Raj
> Cc: OE-core
> Subject: Re: [OE-core] [PATCH 1/1] bitbake.conf: change localedir
> 
> On 8/11/16 2:47 PM, Khem Raj wrote:
> >
> >> On Aug 11, 2016, at 10:11 AM, Mark Hatle <mark.hatle@windriver.com> wrote:
> >>
> >> On 8/11/16 11:26 AM, Burton, Ross wrote:
> >>>
> >>> On 8 August 2016 at 07:04, Chen Qi <Qi.Chen@windriver.com
> >>> <mailto:Qi.Chen@windriver.com>> wrote:
> >>>
> >>>    Previously, localedir is set to "${libdir}/locale". This would result
> >>>    in locale database installed in '/usr/lib64/locale' in some multilib case.
> >>>    For example, if we build out a multilib x86-64 self-hosted image and we try
> >>>    to build projects on this host, things broke and the following error appears.
> >>>
> >>>      Please use a locale setting which supports utf-8.
> >>>      Python can't change the filesystem locale after loading so we need a utf-8
> >>>    when python starts or things won't work.
> >>>
> >>>    This is because '/usr/lib/locale' is the default one. And actually the
> >>>    nativesdk-glibc is now set to use '/usr/lib/locale'.
> >>>
> >>>
> >>> This is irrelevant as nativesdk-glibc is configured to read the *hosts* locale
> >>> directory.
> >>>
> >>>
> >>>    Thus, we change the setting of 'localedir' to '${nonarch_libdir}/locale' to
> >>>    fix the above problem.
> >>>
> >>>
> >>> I see two issues here:
> >>> 1) should binary locales be considered shared in multilib environments? (libdir
> >>> vs nonarch_libdir)
> >>> 2) what packages are not respecting this variable and hard-coding /usr/lib/locale?
> >>>
> >>> I'm guessing WR think yes to (1), and is the glibc patch you also sent the
> >>> fundamental fix to (2)?
> >>
> >> Binary locales have an endian and alignment setting to them.  If a platform
> >> supports both big and little endian, this common locale would not work.  (That
> >> is extremely rare....)  Also if a platform supports different alignments in
> >> different libraries that could cause an impact as well.  (This is also extremely
> >> unlikely.)
> >
> > Are there any practical existing usecases ?
> 
> At one point there was talk about running little endian and big endian power on
> the same machine.  Same with ARM.  I've never actually seen this implemented.

I have seen it implemented, but it was an odd situation.

IIRC: on Android, an app used a native library in one endian
when the system was running the other.  The context was a bug
report, where the comment (and what brought it to my attention)
was disgust that this was being done.

Not sure this is relevant to this discussion, but it's one data
point to indicate that it was actually done, though not for a
normal Linux system.

Enjoy!

				-- radzy

> The alignment was an issue between different S/390 multilibs at one point.  But
> I've not followed it to see if that is still true.  (Not that S/390 is a target
> for what we're doing.)
> 
> So to my knowledge I'm not aware of any use cases we regularly use in the Yocto
> Project -- but I'm also not aware of -all- use-cases.
> 
> I think the best compromise may be to ensure the value is configurable.  Set it
> to the combined location -- with a note that if the multilibs have a different
> endian or alignment setting, to use the older setting breaking them into the
> multilibs.  (I don't know what, if any changes this would require in glibc to
> know when to use which dir...)
> 
> Plan for the optimized case, support the unusual case.
> 
> --Mark
> 
> >>
> >> The not-binary locales have no such issues BTW.
> >>
> >> --Mark
> >>
> >>> Ross
> >>>
> >>>
> >>
> >> --
> >> _______________________________________________
> >> Openembedded-core mailing list
> >> Openembedded-core@lists.openembedded.org
> >> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> >
> 
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core