On 8/11/16 11:26 AM, Burton, Ross wrote: > > On 8 August 2016 at 07:04, Chen Qi <qi.c...@windriver.com > <mailto:qi.c...@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 > > -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
