locale files and int32_t alignment

Joseph S. Myers joseph@codesourcery.com
Wed Sep 4 01:06:00 GMT 2013


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

-- 
Joseph S. Myers
joseph@codesourcery.com



More information about the Libc-alpha mailing list