bz1311954 - multilib variations in LC_COLLATE files, with fixes

[DJ Delorie]

Rafal Luzynski <digitalfreak@lingonborough.com> writes:
> When this bug is fixed, will the locale archives be the same across
> all builds?

No, but only because big and little endian hosts will still build them
in their native endian-ness.

This fix just makes sure that, for example, i686 and x86-64 builds will
be the same.  But i686 (little endian) will not be the same as s390 (big
endian).

> Well, the decimal fractions are known to be often infinite and never
> accurate in binary systems.

I thought about suggesting 37.5% so that it would happen to be (it's hex
0x0.6), but avoiding FP is still better.

>> /* Same value as before, but "/10" isn't exact */
>>   elem_size = next_prime (elem_size * 14/10);
>
> What about:
>
>   elem_size = next_prime (elem_size * 7/5);

I used 14/10 so that it's (hopefully) obvious it's a replacement for
1.4.

> If it does not have to be exactly 1.4 then what about:
>
>   elem_size = next_prime (elem_size + elem_size / 2);
>
> which is 1.5?

That does grow the hash tables, and thus file size, by another 10%.  I
tried to keep my examples close to the original values, because I don't
know what real-world effect a change in overhead would introduce.

>> Note this math also happens in ./iconv/iconvconfig.c:
>>   hash_size = next_prime (nnames * 1.4); 
>
> I guess this will need the same update.

Yup.