]> code.ossystems Code Review - openembedded-core.git/commit
glibc: use the host locale archive in nativesdk builds
authorRoss Burton <ross.burton@intel.com>
Wed, 6 Jul 2016 09:54:29 +0000 (10:54 +0100)
committerRichard Purdie <richard.purdie@linuxfoundation.org>
Wed, 20 Jul 2016 09:24:54 +0000 (10:24 +0100)
commit75321b6b0f2c0ac667b9350b387b01a188e195c8
treefe30f24cea76ec6c8abe8c0a464c6a2725efa974
parent07ca8a0131f43e9cc2f720e1cdbcb7ba7c074886
glibc: use the host locale archive in nativesdk builds

The nativesdk libc when used by buildtools has a hard requirement on supporting
a UTF-8 locale because Python 3 needs a UTF-8 locale.  However we currently only
ship the C locale, which means that Python attempts to lookup the user's locale
(for example, en_NZ.UTF-8) in the locale archive under it's prefix it fails and
falls back to C.  This the results in Python using ASCII instead of UTF-8 for
file encoding, and bitbake breaks.

Th obvious solution would be to ship all locales, but this would add
approximately 250MB to the size of the buildtools tarball (which is currently
around 30MB).  Generating a binary locale archive reduces this down to 100MB,
but this is still a drastic increase in footprint.  If we ship a subset of
locales in the tarball then there will be users whose locale isn't in the
tarball, and they'll have to change their locale to an "approved" one, which
isn't the best of messages to send to new users.

The alternative is to tell the nativesdk libc that the locale archive isn't
under it own prefix but is in fact at /usr/lib/locale/locale-archive, so the
buildtools libc uses the host locale archive. The locale archive format appears
to be at least fairly stable: our glibc 2.24 can read the locale archive
generated by glibc 2.17 (Centos 7).

[ YOCTO #9775 ]

Signed-off-by: Ross Burton <ross.burton@intel.com>
meta/recipes-core/glibc/glibc_2.24.bb