On 16/09/2026 09:40, tpowa via GNU coreutils Bug Reports wrote:
Am 16.09.26 um 09:08 schrieb Collin Funk:
Hi Tobias,
tpowa via GNU coreutils Bug Reports <[email protected]> writes:
while packaging for Arch Linux, this error on checks bumps up:
FAIL test-strerrorname_np (exit status: 139)
Thanks for your attention.
Thanks for the report and the test-suite.log! I see you are on Linux
7.2.
I ran into this on Fedora 44 as well, and it confused me a bit [1] [2].
I'm not 100% certain, but I suspect Fedora needs to rebuild glibc;
likewise for Arch Linux. I'll share my understanding of the issue, and
you can let me know what you think.
Linux 7.2 added a new error number to all architectures named EFTYPE
[3]. This has existed on the BSDs and macOS for a long time. Therefore,
programs such as this test will expect strerrorname_np to return a
string for the error if it is defined. Here is where that test crashes:
$ gnulib-tool --create-testdir --dir testdir1 strerrorname_np
$ cd testdir1
$ ./configure
$ make check
../build-aux/test-driver: line 119: 396693 Segmentation fault (core dumped) "$@" >>
"$log_file" 2>&1
FAIL: test-strerrorname_np
$ gdb ./gltests/test-strerrorname_np
(gdb) run
(gdb) bt
#0 __strcmp_avx2 () at ../sysdeps/x86_64/multiarch/strcmp-avx2.S:283
#1 0x0000000000400ea2 in streq (__s1=<optimized out>, __s2=0x4045d7
"EFTYPE") at ../gllib/string.h:1370
#2 main () at test-strerrorname_np.c:490
(gdb) list test-strerrorname_np.c:488,491
488 /* Mac OS X, FreeBSD, NetBSD, OpenBSD, Minix, Cygwin */
489 #if defined EFTYPE
490 ASSERT (streq (strerrorname_np (EFTYPE), "EFTYPE"));
491 #endif
Gnulib doesn't replace strerrorname_np since it expects it to handle all
of the error numbers supported by the system, as the function is
documented to do [4]. This is true, apparently, until Linux decides to
add an error number that other platforms have historically supported.
The strerrorname_np function, and related functions, use an error list
defined in sysdeps/gnu/errlist.h from glibc. Here is where EFTYPE is
defined:
#ifdef EFTYPE
_S(EFTYPE, N_("Inappropriate file type or format"))
#endif
So, I suspect your glibc was built against Linux 7.1 headers where this
errno isn't defined. Therefore, the error string does not exist, and
strerrorname_np returns a NULL pointer, which is then dereferenced by
the test. Do you know whether that is the case?
Collin
[1]
https://inbox.sourceware.org/libc-alpha/[email protected]/T/#m873e2fbf61fafaec6c9ad226d592d607bcffeecd
[2]
https://inbox.sourceware.org/libc-alpha/[email protected]/T/#m791fba3eaad3ef2f38c813a63dacac715e7325a8
[3]
https://github.com/torvalds/linux/commit/cf1b04aaef8b83f668fac10bfc4d4d76ba6e6fa1
[4] https://manpages.debian.org/testing/manpages-dev/strerrorname_np.3.en.html
Hi Collin,
Thanks for your hint.
Yes you are right, our glibc was built against 7.1.
So this would have failed if the previous coreutils 9.11 was built on kernel
7.2 also.
It sounds like gl_CHECK_STRERRORNAME_NP could be augmented to checking EFTYPE
like it does for other problematic errnos.
cheers,
Padraig
