public inbox for openembedded-core@lists.openembedded.org
 help / color / mirror / Atom feed
From: ChenQi <Qi.Chen@windriver.com>
To: "Burton, Ross" <ross.burton@intel.com>
Cc: OE-core <openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 1/1] bitbake.conf: change localedir
Date: Fri, 12 Aug 2016 11:28:07 +0800	[thread overview]
Message-ID: <57AD4247.7080704@windriver.com> (raw)
In-Reply-To: <CAJTo0LaULRXouHYMfKCMUmtFERseR9vZhWXeC-yK9GLrMTwofQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2621 bytes --]

On 08/12/2016 12:26 AM, Burton, Ross wrote:
>
> On 8 August 2016 at 07:04, Chen Qi <Qi.Chen@windriver.com 
> <mailto: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


[-- Attachment #2: Type: text/html, Size: 5811 bytes --]

      parent reply	other threads:[~2016-08-12  3:28 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-08  6:04 [PATCH 0/1] bitbake.conf: change localedir Chen Qi
2016-08-08  6:04 ` [PATCH 1/1] " Chen Qi
2016-08-10  5:49   ` [PATCH] glibc: apply complocaledir while localedir changed Hongxu Jia
2016-08-10  5:55     ` Hongxu Jia
2016-08-10  7:31   ` [PATCH V2] " Hongxu Jia
2016-08-10  8:12   ` [PATCH V3] " Hongxu Jia
2016-08-11 16:26   ` [PATCH 1/1] bitbake.conf: change localedir Burton, Ross
2016-08-11 17:11     ` Mark Hatle
2016-08-11 19:14       ` Burton, Ross
2016-08-11 19:32         ` Mark Hatle
2016-08-11 19:47       ` Khem Raj
2016-08-12 13:50         ` Mark Hatle
2016-08-12 14:30           ` Radzykewycz, T (Radzy)
2016-08-12  3:28     ` ChenQi [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=57AD4247.7080704@windriver.com \
    --to=qi.chen@windriver.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=ross.burton@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox