This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: locale files and int32_t alignment
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: "Ryan S. Arnold" <ryan dot arnold at gmail dot com>
- Cc: libc-alpha <libc-alpha at sourceware dot org>
- Date: Thu, 12 Sep 2013 19:49:02 +0000
- Subject: Re: locale files and int32_t alignment
- Authentication-results: sourceware.org; auth=none
- References: <Pine dot LNX dot 4 dot 64 dot 1309040055321 dot 27960 at digraph dot polyomino dot org dot uk> <CAAKybw-Mpd6s-6sBNObufEx=36HWg+XKR6=OBqmgXxejUhUH+g at mail dot gmail dot com>
On Thu, 12 Sep 2013, Ryan S. Arnold wrote:
> 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.
There may be triples available to reflect different endianness, but that
doesn't mean they are what people actually use with their compilers (as
opposed to options such as -mbig-endian), or that we should be encouraging
people to treat triples as meaningful at that level. Options such as
--big-endian to localedef are a lot more meaningful and simpler. (And
there doesn't seem to have been any interest in actually preserving the
dependence of locale files on int32_t alignment, char signedness or page
size, so making --big-endian / --little-endian hopefully the only such
options needed.)
Now, if cross-ldconfig were to be merged, the architecture dependencies
there are a lot more complicated (I understand). But while it's on the
list of native/cross feature-parity issues
<https://sourceware.org/glibc/wiki/Development_Todo/Master#Cross_build_.2BAC8_test_improvements>,
it's not something I plan to work on.
--
Joseph S. Myers
joseph@codesourcery.com