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: "Ryan S. Arnold" <ryan dot arnold at gmail dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: libc-alpha <libc-alpha at sourceware dot org>
- Date: Thu, 12 Sep 2013 15:30:07 -0500
- 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> <Pine dot LNX dot 4 dot 64 dot 1309121943510 dot 28584 at digraph dot polyomino dot org dot uk>
On Thu, Sep 12, 2013 at 2:49 PM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> 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.)
Understood.
> 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.
On the topic of cross-ldconfig (for archiving purposes), the cache
'compare' function is extremely naive and should be a target dependent
implementation. It's naive for ldconfig to consider that hwcap weight
alone should indicate library (path) selection preference.
Ryan S. Arnold