Re: locale files and int32_t alignment

["Ryan S. Arnold" <ryan dot arnold at gmail dot com>]

On Tue, Sep 3, 2013 at 8:06 PM, Joseph S. Myers <joseph@codesourcery.com> wrote:
> Locale files output by localedef depend on the architecture (and so go in
> /usr/lib/locale not /usr/share/locale) in two ways:
>
> (a) Various values depend on endianness.
>
> (b) The alignment of collation weights in the files depends on the
> alignment of int32_t.  I believe m68k is the only supported architecture
> for which this is not 4 (it's 2 there).
>
> I'm working on extracting and merging the changes from EGLIBC to make
> localedef support generating locale files for another system.  (I do not
> propose to merge anything related to the separate build system for
> cross-localedef.)
>
> For (a), this involves appropriate command-line options --big-endian and
> --little-endian.  For (b), those changes involve another option
> --uint32-align.  But it's not so clear that this architecture dependence
> makes sense.  Most alignment in locale files uses (in localedef) hardcoded
> sizeof (uint32_t) or 4 or 3 or similar expressions or constants (depending
> on the exact alignment logic in each place), even if only the possibly
> smaller alignment of int32_t is actually relevant.  Perhaps we should
> actually change the relevant code - in both localedef and libc - to use
> sizeof instead of alignof, and so eliminate this architecture dependence?
> (I believe it is always required that binary locale data is built with
> localedef matching the glibc version in use - that there is no
> compatibility requirement for the binary format to remain unchanged.)

Would having the localdef program take a platform triple (as a host
platform override) be enough information to use to solve all of these
problems for a cross generation?  I believe that in the case of
systems with bi-endian support that endianess is in the triple.

But perhaps that'd be more work than it's worth for the common case to
support all of the variations at runtime.

Ryan