[PATCH 0/1] bitbake.conf: change localedir

[PATCH 0/1] bitbake.conf: change localedir

[Chen Qi]

The following changes since commit c4dda05cb9755cb865c1d1bd142196f8a9f45d3d:

  Revert "packagegroup-core-x11-base.bb: replace pointercal with pointercal-xinput" (2016-08-04 20:54:57 +0100)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib ChenQi/locale-fix
  http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=ChenQi/locale-fix

Chen Qi (1):
  bitbake.conf: change localedir

 meta/conf/bitbake.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
1.9.1

[PATCH 1/1] bitbake.conf: change localedir

[Chen Qi]

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'.

Thus, we change the setting of 'localedir' to '${nonarch_libdir}/locale' to
fix the above problem.

Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
---
 meta/conf/bitbake.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index c32a3f8..ed77ee3 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -44,7 +44,7 @@ export libdir = "${exec_prefix}/${baselib}"
 export libexecdir = "${exec_prefix}/libexec"
 export includedir = "${exec_prefix}/include"
 export oldincludedir = "${exec_prefix}/include"
-localedir = "${libdir}/locale"
+localedir = "${nonarch_libdir}/locale"
 
 # Linkage between native/cross/nativesdk layouts
 base_bindir_native = "/bin"
-- 
1.9.1

[PATCH] glibc: apply complocaledir while localedir changed

[Hongxu Jia]

Since localedir changed, we should apply complocaledir=/usr/lib/locale

Build image with IMAGE_LINGUAS="en-us en-gb"

Boot target and display all locales:
...
root@localhost:~# locale -a
C
POSIX
en_GB
en_US
...

Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
---
 meta/recipes-core/glibc/glibc_2.24.bb | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/meta/recipes-core/glibc/glibc_2.24.bb b/meta/recipes-core/glibc/glibc_2.24.bb
index 88bcbef2..219370c 100644
--- a/meta/recipes-core/glibc/glibc_2.24.bb
+++ b/meta/recipes-core/glibc/glibc_2.24.bb
@@ -128,9 +128,7 @@ do_compile () {
 
 }
 
-# Use the host locale archive when built for nativesdk so that we don't need to
-# ship a complete (100MB) locale set.
-do_compile_prepend_class-nativesdk() {
+do_compile_prepend() {
     echo "complocaledir=/usr/lib/locale" >> ${S}/configparms
 }
 
-- 
2.8.1

Re: [PATCH] glibc: apply complocaledir while localedir changed

[Hongxu Jia]

On 08/10/2016 01:49 PM, Hongxu Jia wrote:
> Since localedir changed, we should apply complocaledir=/usr/lib/locale
>
> Build image with IMAGE_LINGUAS="en-us en-gb"
>
> Boot target and display all locales:
> ...
> root@localhost:~# locale -a
> C
> POSIX
> en_GB
> en_US
> ...
>
> Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
> ---
>   meta/recipes-core/glibc/glibc_2.24.bb | 4 +---
>   1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/meta/recipes-core/glibc/glibc_2.24.bb b/meta/recipes-core/glibc/glibc_2.24.bb
> index 88bcbef2..219370c 100644
> --- a/meta/recipes-core/glibc/glibc_2.24.bb
> +++ b/meta/recipes-core/glibc/glibc_2.24.bb
> @@ -128,9 +128,7 @@ do_compile () {
>   
>   }
>   
> -# Use the host locale archive when built for nativesdk so that we don't need to
> -# ship a complete (100MB) locale set.
> -do_compile_prepend_class-nativesdk() {
> +do_compile_prepend() {
>       echo "complocaledir=/usr/lib/locale" >> ${S}/configparms

Please drop this, It should be "complocaledir=${localedir}" better.

//Hongxu

>   }
>   

[PATCH V2] glibc: apply complocaledir while localedir changed

[Hongxu Jia]

Since localedir changed, we should apply complocaledir=${localedir}

Build image with IMAGE_LINGUAS="en-us en-gb"

Boot target and display all locales:
...
root@localhost:~# locale -a
C
POSIX
en_GB
en_US
...

Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
---
 meta/recipes-core/glibc/glibc_2.24.bb | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/meta/recipes-core/glibc/glibc_2.24.bb b/meta/recipes-core/glibc/glibc_2.24.bb
index 88bcbef2..2f0c4be 100644
--- a/meta/recipes-core/glibc/glibc_2.24.bb
+++ b/meta/recipes-core/glibc/glibc_2.24.bb
@@ -128,10 +128,8 @@ do_compile () {
 
 }
 
-# Use the host locale archive when built for nativesdk so that we don't need to
-# ship a complete (100MB) locale set.
-do_compile_prepend_class-nativesdk() {
-    echo "complocaledir=/usr/lib/locale" >> ${S}/configparms
+do_compile_prepend() {
+    echo "complocaledir=${localedir}" >> ${S}/configparms
 }
 
 require glibc-package.inc
-- 
2.8.1

[PATCH V3] glibc: apply complocaledir while localedir changed

[Hongxu Jia]

Since localedir changed
-----------------------
commit bbca0646c7b55aa28dbf796ab9135bbc63a92a8d
Author: Chen Qi <Qi.Chen@windriver.com>
Date:   Mon Aug 8 13:55:42 2016 +0800

    bitbake.conf: change localedir
-----------------------

Refer nativesdk, We should apply complocaledir=${localedir} for target.

Build image with IMAGE_LINGUAS="en-us en-gb"

Boot target and display all locales:
...
root@localhost:~# locale -a
C
POSIX
en_GB
en_US
...

(LOCAL REV: NOT UPSTREAM) -- sent to oe-core on 20160810

Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
---
 meta/recipes-core/glibc/glibc_2.24.bb | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/meta/recipes-core/glibc/glibc_2.24.bb b/meta/recipes-core/glibc/glibc_2.24.bb
index 88bcbef2..c1b5190 100644
--- a/meta/recipes-core/glibc/glibc_2.24.bb
+++ b/meta/recipes-core/glibc/glibc_2.24.bb
@@ -134,6 +134,10 @@ do_compile_prepend_class-nativesdk() {
     echo "complocaledir=/usr/lib/locale" >> ${S}/configparms
 }
 
+do_compile_prepend_class-target() {
+    echo "complocaledir=${localedir}" >> ${S}/configparms
+}
+
 require glibc-package.inc
 
 BBCLASSEXTEND = "nativesdk"
-- 
2.8.1

Re: [PATCH 1/1] bitbake.conf: change localedir

[Burton, Ross]

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

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.


> 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)
2) what packages are not respecting this variable and hard-coding
/usr/lib/locale?

I'm guessing WR think yes to (1), and is the glibc patch you also sent the
fundamental fix to (2)?

Ross

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

Re: [PATCH 1/1] bitbake.conf: change localedir

[Mark Hatle]

On 8/11/16 11: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.
>  
> 
>     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)
> 2) what packages are not respecting this variable and hard-coding /usr/lib/locale?
> 
> I'm guessing WR think yes to (1), and is the glibc patch you also sent the
> fundamental fix to (2)?

Binary locales have an endian and alignment setting to them.  If a platform
supports both big and little endian, this common locale would not work.  (That
is extremely rare....)  Also if a platform supports different alignments in
different libraries that could cause an impact as well.  (This is also extremely
unlikely.)

The not-binary locales have no such issues BTW.

--Mark

> Ross
> 
> 

Re: [PATCH 1/1] bitbake.conf: change localedir

[Burton, Ross]

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

On 11 August 2016 at 18:11, Mark Hatle <mark.hatle@windriver.com> wrote:

> Binary locales have an endian and alignment setting to them.  If a platform
> supports both big and little endian, this common locale would not work.
> (That
> is extremely rare....)  Also if a platform supports different alignments in
> different libraries that could cause an impact as well.  (This is also
> extremely
> unlikely.)
>

So by that logic this patch should be rejected, right?

This path is for the compiled locale definitions - LC_TYPE etc and the
locale archive, right?  So it's only glibc-locales that ships in here, not
other packages (just trying to check my assumptions)

Ross

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

Re: [PATCH 1/1] bitbake.conf: change localedir

[Mark Hatle]

On 8/11/16 2:14 PM, Burton, Ross wrote:
> 
> On 11 August 2016 at 18:11, Mark Hatle <mark.hatle@windriver.com
> <mailto:mark.hatle@windriver.com>> wrote:
> 
>     Binary locales have an endian and alignment setting to them.  If a platform
>     supports both big and little endian, this common locale would not work.  (That
>     is extremely rare....)  Also if a platform supports different alignments in
>     different libraries that could cause an impact as well.  (This is also extremely
>     unlikely.)
> 
> 
> So by that logic this patch should be rejected, right?

The binary bits was why it was not originally implemented this way.  HOWEVER,
are there are conflicting cases we have to worry about for the binaries?  If
there are not any reasonable cases -- then this may save a huge amount of space
for a device that contains a number of binary locales.

(In otherwords, I don't object to the patch due to those reasons -- I just want
it to be clear to folks that there are binary nuances to this, it is extremely
rare that it's a problem, so rare it may simply NOT be an issue in our
configuration.  But these can never be 'noarch' packages as they are tied to an
arch.)

--Mark

> This path is for the compiled locale definitions - LC_TYPE etc and the locale
> archive, right?  So it's only glibc-locales that ships in here, not other
> packages (just trying to check my assumptions)
> 
> Ross

Re: [PATCH 1/1] bitbake.conf: change localedir

[Khem Raj]

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


> On Aug 11, 2016, at 10:11 AM, Mark Hatle <mark.hatle@windriver.com> wrote:
> 
> On 8/11/16 11: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.
>> 
>> 
>>    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)
>> 2) what packages are not respecting this variable and hard-coding /usr/lib/locale?
>> 
>> I'm guessing WR think yes to (1), and is the glibc patch you also sent the
>> fundamental fix to (2)?
> 
> Binary locales have an endian and alignment setting to them.  If a platform
> supports both big and little endian, this common locale would not work.  (That
> is extremely rare....)  Also if a platform supports different alignments in
> different libraries that could cause an impact as well.  (This is also extremely
> unlikely.)

Are there any practical existing usecases ?

> 
> The not-binary locales have no such issues BTW.
> 
> --Mark
> 
>> Ross
>> 
>> 
> 
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: [PATCH 1/1] bitbake.conf: change localedir

[ChenQi]

[-- 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 --]

Re: [PATCH 1/1] bitbake.conf: change localedir

[Mark Hatle]

On 8/11/16 2:47 PM, Khem Raj wrote:
> 
>> On Aug 11, 2016, at 10:11 AM, Mark Hatle <mark.hatle@windriver.com> wrote:
>>
>> On 8/11/16 11: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.
>>>
>>>
>>>    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)
>>> 2) what packages are not respecting this variable and hard-coding /usr/lib/locale?
>>>
>>> I'm guessing WR think yes to (1), and is the glibc patch you also sent the
>>> fundamental fix to (2)?
>>
>> Binary locales have an endian and alignment setting to them.  If a platform
>> supports both big and little endian, this common locale would not work.  (That
>> is extremely rare....)  Also if a platform supports different alignments in
>> different libraries that could cause an impact as well.  (This is also extremely
>> unlikely.)
> 
> Are there any practical existing usecases ?

At one point there was talk about running little endian and big endian power on
the same machine.  Same with ARM.  I've never actually seen this implemented.

The alignment was an issue between different S/390 multilibs at one point.  But
I've not followed it to see if that is still true.  (Not that S/390 is a target
for what we're doing.)

So to my knowledge I'm not aware of any use cases we regularly use in the Yocto
Project -- but I'm also not aware of -all- use-cases.

I think the best compromise may be to ensure the value is configurable.  Set it
to the combined location -- with a note that if the multilibs have a different
endian or alignment setting, to use the older setting breaking them into the
multilibs.  (I don't know what, if any changes this would require in glibc to
know when to use which dir...)

Plan for the optimized case, support the unusual case.

--Mark

>>
>> The not-binary locales have no such issues BTW.
>>
>> --Mark
>>
>>> Ross
>>>
>>>
>>
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> 

Re: [PATCH 1/1] bitbake.conf: change localedir

[Radzykewycz, T (Radzy)]

________________________________________
> From: openembedded-core-bounces@lists.openembedded.org [openembedded-core-bounces@lists.openembedded.org] on behalf of Mark Hatle [mark.hatle@windriver.com]
> Sent: Friday, August 12, 2016 6:50 AM
> To: Khem Raj
> Cc: OE-core
> Subject: Re: [OE-core] [PATCH 1/1] bitbake.conf: change localedir
> 
> On 8/11/16 2:47 PM, Khem Raj wrote:
> >
> >> On Aug 11, 2016, at 10:11 AM, Mark Hatle <mark.hatle@windriver.com> wrote:
> >>
> >> On 8/11/16 11: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.
> >>>
> >>>
> >>>    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)
> >>> 2) what packages are not respecting this variable and hard-coding /usr/lib/locale?
> >>>
> >>> I'm guessing WR think yes to (1), and is the glibc patch you also sent the
> >>> fundamental fix to (2)?
> >>
> >> Binary locales have an endian and alignment setting to them.  If a platform
> >> supports both big and little endian, this common locale would not work.  (That
> >> is extremely rare....)  Also if a platform supports different alignments in
> >> different libraries that could cause an impact as well.  (This is also extremely
> >> unlikely.)
> >
> > Are there any practical existing usecases ?
> 
> At one point there was talk about running little endian and big endian power on
> the same machine.  Same with ARM.  I've never actually seen this implemented.

I have seen it implemented, but it was an odd situation.

IIRC: on Android, an app used a native library in one endian
when the system was running the other.  The context was a bug
report, where the comment (and what brought it to my attention)
was disgust that this was being done.

Not sure this is relevant to this discussion, but it's one data
point to indicate that it was actually done, though not for a
normal Linux system.

Enjoy!

				-- radzy

> The alignment was an issue between different S/390 multilibs at one point.  But
> I've not followed it to see if that is still true.  (Not that S/390 is a target
> for what we're doing.)
> 
> So to my knowledge I'm not aware of any use cases we regularly use in the Yocto
> Project -- but I'm also not aware of -all- use-cases.
> 
> I think the best compromise may be to ensure the value is configurable.  Set it
> to the combined location -- with a note that if the multilibs have a different
> endian or alignment setting, to use the older setting breaking them into the
> multilibs.  (I don't know what, if any changes this would require in glibc to
> know when to use which dir...)
> 
> Plan for the optimized case, support the unusual case.
> 
> --Mark
> 
> >>
> >> The not-binary locales have no such issues BTW.
> >>
> >> --Mark
> >>
> >>> Ross
> >>>
> >>>
> >>
> >> --
> >> _______________________________________________
> >> Openembedded-core mailing list
> >> Openembedded-core@lists.openembedded.org
> >> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> >
> 
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core