[OE-core] [PATCH 1/1] bitbake.conf: change localedir

[Khem Raj]

> On Aug 11, 2016, at 10:11 AM, Mark Hatle <mark.hatle at windriver.com> wrote:
> 
> 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.)

Are there any practical existing usecases ?

> 
> The not-binary locales have no such issues BTW.
> 
> --Mark
> 
>> Ross
>> 
>> 
> 
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20160811/0068d878/attachment-0002.sig>