FYI, I was building coreutils and noticed that the strerrorname_np test
failed.
Here is a simplified example:
$ 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
The culprit can be seen from my dnf logs:
$ dnf history info 716 | grep kernel-0
Install kernel-0:7.2.4-200.fc44.x86_64 User updates
Remove kernel-0:7.1.10-200.fc44.x86_64 User @System
The EFTYPE errno was added in Linux 7.2 [1]. I've CC'ed libc-alpha since
they were clearly not given a heads up, which suprised me:
$ git log --grep=EFTYPE
commit 8619129f3f0d5a9db6208be5bae6c2a8c9ce61a5
Author: Ulrich Drepper <[email protected]>
AuthorDate: Mon Apr 20 18:41:05 1998 +0000
Commit: Ulrich Drepper <[email protected]>
CommitDate: Mon Apr 20 18:41:05 1998 +0000
Is that how it typically works? It seems a bit unfortuante to need to
wait for someones program to crash, luckily just a test in this case,
before it is noticed. See the following built without Gnulib:
$ cat main.c
#define _GNU_SOURCE 1
#include <stdio.h>
#include <string.h>
#include <errno.h>
int
main (void)
{
printf ("%s\n", strerrorname_np (EPERM));
printf ("%s\n", strerrorname_np (EFTYPE));
return 0;
}
$ gcc main.c; ./a.out
EPERM
Segmentation fault (core dumped) ./a.out
Collin
[1]
https://github.com/torvalds/linux/commit/cf1b04aaef8b83f668fac10bfc4d4d76ba6e6fa1
