[OE-core] [for-krogoth] Backport "glibc: use the host locale archive in nativesdk builds"
Otavio Salvador
otavio.salvador at ossystems.com.br
Fri Aug 12 16:40:20 UTC 2016
Hello Armin,
The commit OE-Core:75321b6b0f2c0ac667b9350b387b01a188e195c8 is need
for Krogoth. See the full commit log below:
Author: Ross Burton <ross.burton at intel.com>
Date: Wed Jul 6 10:54:29 2016 +0100
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 at intel.com>
The uninative tarball from Krogoth does not include that so native
tools which require locale usage fails badly. I found this issue while
working in a python3 based tool which is used in the 'native' context
and Richard (CCed) has debugged it with me until we found out that we
need to backport this. The use of the new uninative used on master is
not the best option as it bumps the glibc release and requires other
backports (such as pseudo) so making a 1.0.1 uninative release seems
to be the best choice for stable, thus this request.
Best Regards,
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
More information about the Openembedded-core
mailing list