GNU bug report logs - #76550
30.1; Test failure for fns-tests-collate-strings with musl libc

Previous Next

Package: emacs;

Reported by: Ulrich Müller <ulm <at> gentoo.org>

Date: Tue, 25 Feb 2025 11:53:01 UTC

Severity: minor

Found in version 30.1

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Ulrich Müller <ulm <at> gentoo.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Ulrich Müller <ulm <at> gentoo.org>, Paul Eggert <eggert <at> cs.ucla.edu>, 76550 <at> debbugs.gnu.org
Subject: bug#76550: 30.1; Test failure for fns-tests-collate-strings with musl libc
Date: Wed, 26 Feb 2025 15:44:43 +0100
>>>>> On Wed, 26 Feb 2025, Eli Zaretskii wrote:

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

Tests are enabled in Gentoo, so we have to disable any failing tests
in our ebuild. IIUC the only method is via EXCLUDE_TESTS which operates
on the file level, i.e. disabling one specific test isn't even possible.
So yes, it is a problem.

> But okay, matching the system-configuration string might also be okay,

In fact, I went with the documentation of system-type in the lispref
manual:

| If you need to make a finer distinction than ‘system-type’ allows for,
| you can test ‘system-configuration’, e.g., against a regexp."

> just add a comment there explaining why we do that.

Sure, can do.

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

Why? I don't see how disabling this test could break anything. (And I'd
really like to have it fixed in the next release.)

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




This bug report was last modified 82 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.