On 8/11/16 2:47 PM, Khem Raj wrote: > >> On Aug 11, 2016, at 10:11 AM, Mark Hatle <[email protected]> wrote: >> >> On 8/11/16 11:26 AM, Burton, Ross wrote: >>> >>> On 8 August 2016 at 07:04, Chen Qi <[email protected] >>> <mailto:[email protected]>> 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 >> [email protected] >> http://lists.openembedded.org/mailman/listinfo/openembedded-core > -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
