<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 08/12/2016 12:26 AM, Burton, Ross
wrote:<br>
</div>
<blockquote
cite="mid:CAJTo0LaULRXouHYMfKCMUmtFERseR9vZhWXeC-yK9GLrMTwofQ@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div dir="ltr">
<div class="gmail_extra"><br>
<div class="gmail_quote">On 8 August 2016 at 07:04, Chen Qi <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:Qi.Chen@windriver.com" target="_blank">Qi.Chen@windriver.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":1ir" class="a3s aXjCH m15668c12753f49ff">Previously,
localedir is set to "${libdir}/<span class="il">locale</span>".
This would result<br>
in <span class="il">locale</span> database installed in
'/usr/lib64/<span class="il">locale</span>' in some
multilib case.<br>
For example, if we build out a multilib x86-64
self-hosted image and we try<br>
to build projects on this host, things broke and the
following error appears.<br>
<br>
Please use a <span class="il">locale</span> setting
which supports utf-8.<br>
Python can't change the filesystem <span class="il">locale</span>
after loading so we need a utf-8 when python starts or
things won't work.<br>
<br>
This is because '/usr/lib/<span class="il">locale</span>'
is the default one. And actually the<br>
nativesdk-glibc is now set to use '/usr/lib/<span
class="il">locale</span>'.<br>
</div>
</blockquote>
<div><br>
</div>
<div>This is irrelevant as nativesdk-glibc is configured to
read the *hosts* locale directory.</div>
<div> </div>
</div>
</div>
</div>
</blockquote>
<br>
Hi Ross,<br>
<br>
I think I didn't state things clearly. Sorry for that.<br>
I mentioned nativesdk-glibc because of the following use case.<br>
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.<br>
<br>
<br>
<blockquote
cite="mid:CAJTo0LaULRXouHYMfKCMUmtFERseR9vZhWXeC-yK9GLrMTwofQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":1ir" class="a3s aXjCH m15668c12753f49ff">
Thus, we change the setting of 'localedir' to
'${nonarch_libdir}/<span class="il">locale</span>' to<br>
fix the above problem.</div>
</blockquote>
</div>
<br>
I see two issues here:</div>
<div class="gmail_extra">1) should binary locales be considered
shared in multilib environments? (libdir vs nonarch_libdir)</div>
</div>
</blockquote>
<br>
I think yes.<br>
Below is something from glibc source. The file is
git/sysdeps/unix/sysv/linux/x86_64/64/configure.<br>
<br>
# Locale data can be shared between 32-bit and 64-bit libraries.<br>
libc_cv_complocaledir='${exec_prefix}/lib/locale'<br>
<br>
You can see that it states clearly that the binary data could be
shared and it uses 'lib'.<br>
<br>
<blockquote
cite="mid:CAJTo0LaULRXouHYMfKCMUmtFERseR9vZhWXeC-yK9GLrMTwofQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">2) what packages are not respecting
this variable and hard-coding /usr/lib/locale?</div>
<div class="gmail_extra"><br>
</div>
</div>
</blockquote>
<br>
I don't know. But the manual of locale has stated clearly that
'/usr/lib/locale' is the default directory.<br>
Something from the manual below.<br>
<br>
LOCPATH<br>
<br>
The directory where locale data is stored. By
default, /usr/lib/locale is used.<br>
<br>
<br>
<blockquote
cite="mid:CAJTo0LaULRXouHYMfKCMUmtFERseR9vZhWXeC-yK9GLrMTwofQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">I'm guessing WR think yes to (1), and
is the glibc patch you also sent the fundamental fix to (2)?</div>
<div class="gmail_extra"><br>
</div>
</div>
</blockquote>
<br>
I don't know why the glibc patch is needed.<br>
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.<br>
This might also be related to cross-localedef recipe.<br>
<br>
Best Regards,<br>
Chen Qi<br>
<br>
<blockquote
cite="mid:CAJTo0LaULRXouHYMfKCMUmtFERseR9vZhWXeC-yK9GLrMTwofQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">Ross</div>
</div>
</blockquote>
<br>
</body>
</html>