On 9/24/12 4:04 PM, Chris Larson wrote:
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.

They are endian and locale word size dependent. (It just happens to be that all of our architectures use the unit32-aligned=4 structures.) :)

So they are sharable between ABIs on the same arch for sure.

--Mark

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.



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

Reply via email to