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

From: Eli Zaretskii <[email-masked]>
Date: Wed, 26 Feb 2025 15:21:18 +0200

> From: Ulrich Müller <[email-masked]>
> Cc: Ulrich Müller <[email-masked]>,  [email-masked]
> Date: Tue, 25 Feb 2025 21:12:35 +0100
> 
> >>>>> On Tue, 25 Feb 2025, Eli Zaretskii wrote:
> 
> >> > 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.

If you insist to not have this test fail (is it really a problem?),
then why not do it cleanly?

But okay, matching the system-configuration string might also be okay,
just add a comment there explaining why we do that.

And please install the change on master, not on the release branch.

> >> 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.

Ah, but the code which calls newlocale depends on that validity check.

Maybe Paul has some comments or suggestions.