On Mon, Sep 24, 2012 at 2:11 PM, Mark Hatle <[email protected]> wrote: > 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.
Ah, thanks for the clarification. -- Christopher Larson _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
