On 8 August 2016 at 07:04, Chen Qi <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)?

Ross