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

[Mark Hatle <mark.hatle@windriver.com>]

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.)

The not-binary locales have no such issues BTW.

--Mark

> Ross
> 
>