Re: Custom Glibc collation version strings under LOCPATH

On 6/4/25 09:52, Joe Conway wrote:
> On 6/4/25 00:03, Thomas Munro wrote:
>> One way to move to a newer glibc-based Linux distribution but keep the
>> locales working the same* without keeping the associated zombie C code
>> alive is to find the source system's collation definition source
>> files, compile them with the localedef on the target system and point
>> to the top-level directory with the environment variable LOCPATH.
>
> I don't think this works in all cases because I have seen where sorting
> was affected by C code rather than than data changes.

Sorry I missed this part:

>> I'm interested in hearing about other concrete
>> examples of the locale-recompilation technique failing to be perfect,
>> and getting to the bottom of them; I have yet to hear of a real world
>> system that fails amcheck when using locale definitions ported in this
>> way.

If you go from anything pre-glibc-2.21 to post-glibc-2.21 I think you
will find that even with the same data files you get a different sort.
The same patch that caused the performance regression [1] (still present
in up to date glibc) also cause changes in sort order via C code alone.

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=18441

--
Joe Conway
PostgreSQL Contributors Team
Amazon Web Services: https://aws.amazon.com