9775 2016-06-15 03:51:53 +0000 buildtools results in broken system locale if LANG is not en_US 2016-07-29 15:12:13 +0000 1 1 7 Build System, Metadata & Runtime OE-Core core 2.0 x86 Multiple VERIFIED FIXED Medium+ major 2.2 M2 1 bluelightning ross.burton jose.perez.carranza meta.mr.watcher meta.watcher richard.purdie --- --- Don't know oldest_to_newest 62982 0 bluelightning 2016-06-15 03:51:53 +0000 I just set up a new CentOS system, and there I have LANG set to en_NZ.utf8. I need buildtools to have all the right dependencies, so I installed the latest snapshot from the autobuilder (20160614-1). However, when I try to run bitbake within the buildtools environment, it tells me "Please use a locale setting which supports utf-8.", and indeed if I run python3 and query sys.getfilesystemencoding() it returns 'ascii'. However if I instead run LANG=en_US.utf8 python3 and try the same thing I get the expected 'utf-8'. Initially I thought this was something broken in CentOS, but then I tried installing the python 3.4 package from EPEL and running that instead of the python3 from buildtools, and with that I get the correct 'utf-8' value with LANG set to my default "en_NZ.utf8". Do we perhaps need to ship the locale data files for glibc within buildtools as well now? 63572 1 ross.burton 2016-07-01 11:27:03 +0000 Can you see what happens if you leave LANG=en_NZ.utf8 but set LOCPATH=/usr/share/locale, so the buildtool glibc should look at the host locales? 63616 2 ross.burton 2016-07-04 13:14:25 +0000 Looks like LOCPATH isn't an option. When LOCPATH isn't set glibc uses the locale archive (/usr/lib/locale/locale-archive) which is a mmappable binary representation of the locale database. However when LOCPATH is set it won't look for a locale archive but will look for expanded /usr/lib/locale/[locale]/[key] files, which on at least Debian and Fedora don't exist for most locales (Debian only ships those for C.UTF-8). Instead it is expected that the locale archive is used, and that has a fixed location. I wonder if it would be possible to patch nativesdk-glibc to use the host's locale path... the question here is how stable is the binary locale format? 63672 3 ross.burton 2016-07-06 14:09:27 +0000 Paul, so poky-contrib:ross/sdki18n has a rather special patch for glibc which will mean nativesdk-glibc will look in /usr/ for the locale archive. Can you build a fresh buildtools with that patch and see if it solves your problem on the Centos machine? 63911 4 bluelightning 2016-07-13 05:17:52 +0000 I tested a build with the top commit on ross/sdki18n and that does indeed seem to have fixed the issue - and FWIW I build the buildtools tarball on my Fedora 23 machine and then ran it on CentOS 7, so that may indicate that compatibility isn't going to be too much of an issue either. 63990 5 ross.burton 2016-07-14 16:37:54 +0000 Thanks Paul! 64229 6 ross.burton 2016-07-20 13:44:29 +0000 Fixed in oe-core 75321b6b0f2c0ac667b9350b387b01a188e195c8. 64655 7 jose.perez.carranza 2016-07-29 15:12:13 +0000 Verified that cworks as per Comment 4