Subject: bug#76550: 30.1; Test failure for fns-tests-collate-strings with musl libc

From: Ulrich Müller <[email-masked]>
Date: Tue, 25 Feb 2025 21:12:35 +0100

>>>>> On Tue, 25 Feb 2025, Eli Zaretskii wrote:

>> From: Ulrich Müller <[email-masked]>
>> Cc: Ulrich Müller <[email-masked]>,  [email-masked]
>> Date: Tue, 25 Feb 2025 19:27:53 +0100
>> 
>> >>>>> On Tue, 25 Feb 2025, Eli Zaretskii wrote:
>> 
>> > Are musl builds guaranteed to have "-musl" in system-configuration?
>> > Or is that just in the builds you are doing?
>> 
>> musl.m4 from Gnulib does this:
>> 
>> case "$host_os" in
>> *-musl* | midipix*)
>> AC_DEFINE([MUSL_LIBC], [1], [Define to 1 on musl libc.])
>> ;;
>> esac

> So it could also be "midipix"?

midipix seems to be a development environment on Windows (using musl,
I guess?), see https://midipix.org/. We could of course check for both
strings, but I have no way to test with midipix.

>> > II thought about using some musl-specific symbol, or even creating one
>> > if none already exists.
>> 
>> I cannot find any such symbol in the sources.

> We could make a new symbol, if that's useful.

That feels a little over-engineered just to control a single test, at
least for my taste.

>> Presumably, the most specific feature check would be for the return
>> value of newlocale(3), depending on its second argument. Then again,
>> newlocale is called by str_collate (in sysdep.c), which in turn is
>> called by string-collate-equalp.
>> 
>> Effectively, the test checks for the exact feature that we need, in
>> order to decide whether the test should be called. :) IMHO it is pretty
>> much pointless.

> Sorry, you lost me here.

The test succeeds with glibc, where newlocale checks validity of the
locale. And it fails with musl, where newlocale's checks are lenient.
So one could say that the test is for a feature of the C library but not
for any feature of Emacs.