This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

locale files and int32_t alignment


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]