From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail5.wrs.com (mail5.windriver.com [192.103.53.11]) by mail.openembedded.org (Postfix) with ESMTP id E02CE73D27 for ; Fri, 12 Aug 2016 03:28:08 +0000 (UTC) Received: from ALA-HCA.corp.ad.wrs.com (ala-hca.corp.ad.wrs.com [147.11.189.40]) by mail5.wrs.com (8.15.2/8.15.2) with ESMTPS id u7C3S65Z008589 (version=TLSv1 cipher=AES128-SHA bits=128 verify=OK); Thu, 11 Aug 2016 20:28:06 -0700 Received: from [128.224.162.229] (128.224.162.229) by ALA-HCA.corp.ad.wrs.com (147.11.189.50) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 11 Aug 2016 20:28:05 -0700 To: "Burton, Ross" References: <8374cee610f770f4e027f92785bc0bed13334fbb.1470636212.git.Qi.Chen@windriver.com> From: ChenQi Message-ID: <57AD4247.7080704@windriver.com> Date: Fri, 12 Aug 2016 11:28:07 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: X-Originating-IP: [128.224.162.229] Cc: OE-core Subject: Re: [PATCH 1/1] bitbake.conf: change localedir X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2016 03:28:10 -0000 Content-Type: multipart/alternative; boundary="------------080403070204080903030206" --------------080403070204080903030206 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit On 08/12/2016 12:26 AM, Burton, Ross wrote: > > On 8 August 2016 at 07:04, Chen Qi > 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 --------------080403070204080903030206 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit
On 08/12/2016 12:26 AM, Burton, Ross wrote:

On 8 August 2016 at 07:04, Chen Qi <Qi.Chen@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

--------------080403070204080903030206--