This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
locale files and page size
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: <libc-alpha at sourceware dot org>
- Date: Wed, 11 Sep 2013 01:52:09 +0000
- Subject: locale files and page size
- Authentication-results: sourceware.org; auth=none
In <https://sourceware.org/ml/libc-alpha/2013-09/msg00109.html> I noted
two sources of architecture-dependence of locale files: endianness and
int32_t alignment.
I'd still welcome comments in reply to that message about the second of
those issues - whether localedef should get an option to specify this
alignment, for generating locales for other systems, or whether this
architecture-dependence should be removed. However, I've now found a
third source of architecture-dependence.
The locarchive.c code aligns some locale data in the archive file to page
boundaries, where pages are determined by getpagesize on the system
running localedef. This makes the archive (but not the separate locale
files, if use of the archive is disabled) depend on the page size of the
system running localedef - which is not only architecture-dependent, but
may also vary among systems with the same architecture.
Now, I think this alignment is just some sort of optimization, so
differences in page size don't affect the functionality of the binary
locale data if used on a system with a different page size. However, if
the optimization makes sense at all, then when generating locales for a
different system the appropriate page size for that system should be used.
Furthermore, with interest recently in making builds of GNU/Linux
distributions produce independently reproducible binaries, there should be
a way to eliminate any such dependence on the system on which localedef
was run.
So: should we simply eliminate this page-alignment optimization completely
(I rather doubt it makes any significant difference to the cost of loading
a locale from the archive) - or should it change to use an
architecture-independent constant instead of calling getpagesize - or
should it use an architecture-dependent constant (sufficient for the
reproducible builds issue) together with a command-line option to change
the assumed page size for the cross-build case - or should the default
continue to be as at present, but with such a command-line option for both
the cross-build and reproducible-build cases?
--
Joseph S. Myers
joseph@codesourcery.com