Re: locale files and int32_t alignment

["Ryan S. Arnold" <ryan dot arnold at gmail dot com>]

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