On Mon, Sep 24, 2012 at 2:00 PM, Khem Raj <[email protected]> wrote:
> On Mon, Sep 24, 2012 at 12:00 PM, Christopher Larson <[email protected]> 
> wrote:
>> From: Christopher Larson <[email protected]>
>>
>> This avoids the hardcoding of ${libdir}/locale which is all over the place,
>> and will facilitate use of ${exec_prefix}/lib/locale instead of
>> ${libdir}/locale.
>
> what is adavantage of letting use ${exec_prefix}/lib/locale ? Do you have a 
> case
> where you share locale between multilibs ?

This is the case by default for all eglibc builds that set libdir to
the default. See https://gist.github.com/3756705 — there's another
block just like that for all the other 64 bit archs for eglibc. When
we pass —libdir=/usr/lib64, it skips this logic.

So changing it would just bring us inline with the default eglibc
behavior. The binary locale files are, as far as I'm aware, a
relatively arch independent binary format. There's no point or benefit
to having lib32 vs lib64 copies, they'd just be duplicated content.

If it wasn't for the forthcoming 1.3 release, I'd have included the
proposed change to the default localedir to ${exec_prefix}/lib/locale
with this patch.
-- 
Christopher Larson

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Reply via email to