[OE-core] [PATCH 1/1] bitbake.conf: change localedir
Mark Hatle
mark.hatle at windriver.com
Thu Aug 11 17:11:48 UTC 2016
On 8/11/16 11:26 AM, Burton, Ross wrote:
>
> On 8 August 2016 at 07:04, Chen Qi <Qi.Chen at windriver.com
> <mailto:Qi.Chen at 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
>
>
More information about the Openembedded-core
mailing list