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

[Mark Hatle]

On 8/11/16 2:47 PM, Khem Raj wrote:
> 
>> 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 ?

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.

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 at lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>