On 08/12/2016 12: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.
Hi Ross,
I think I didn't state things clearly. Sorry for that.
I mentioned nativesdk-glibc because of the following use case.
On a self-hosted image, which is built out by Yocto, we install
buildtools-tarball, make use of it and start building. This is why I
mentioned nativesdk-glibc.
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)
I think yes.
Below is something from glibc source. The file is
git/sysdeps/unix/sysv/linux/x86_64/64/configure.
# Locale data can be shared between 32-bit and 64-bit libraries.
libc_cv_complocaledir='${exec_prefix}/lib/locale'
You can see that it states clearly that the binary data could be shared
and it uses 'lib'.
2) what packages are not respecting this variable and hard-coding
/usr/lib/locale?
I don't know. But the manual of locale has stated clearly that
'/usr/lib/locale' is the default directory.
Something from the manual below.
LOCPATH
The directory where locale data is stored. By default,
/usr/lib/locale is used.
I'm guessing WR think yes to (1), and is the glibc patch you also sent
the fundamental fix to (2)?
I don't know why the glibc patch is needed.
At a first glance, I think it might be related to
GLIBC_INTERNAL_USE_BINARY_LOCALE handling. The value of this variable is
overridden in our bbappend file.
This might also be related to cross-localedef recipe.
Best Regards,
Chen Qi
Ross
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
