[PATCH] tests: Skip signal detection on Haiku
On Haiku, using 'kill -9' fromm /bin/shactually causes a process to
die with the non-standard SIGKILLTHR 15, which causes 198.sysval to
fail from the unexpected value.
* doc/m4.texi (Sysval): Skip test on Haiku.
Reported by Bruno Haible,
https://lists.gnu.org/archive/html/bug-m4/2021-05/msg4.html
---
doc/m4.texi | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/doc/m4.texi b/doc/m4.texi
index 7dcbb5ce..94ac851d 100644
--- a/doc/m4.texi
+++ b/doc/m4.texi
@@ -6745,14 +6745,22 @@ Sysval
@comment systems where /bin/sh does not create its own process group.
@comment And PIPE is unreliable, since people tend to run with it
@comment ignored, with m4 inheriting that choice. That leaves KILL as
-@comment the only signal we can reliably test.
+@comment the only signal we can reliably test, but even that is tricky:
+@comment on Haiku, 'kill -9' actually causes a process to die with
+@comment signal 15 named KILLTHR on that platform.
@example
dnl This test assumes kill is a shell builtin, and that signals are
dnl recognizable.
ifdef(`__unix__', ,
`errprint(` skipping: syscmd does not have unix semantics
')m4exit(`77')')dnl
-syscmd(`kill -9 $$')
+changequote(`[', `]')
+@result{}
+syscmd([/bin/sh -c 'kill -9 $$'; st=$?; test $st = 137 || test $st = 265])
+@result{}
+ifelse(sysval, [0], , [errprint([ skipping: shell does not send signal 9
+])m4exit([77])])dnl
+syscmd([kill -9 $$])
@result{}
sysval
@result{}2304
@@ -6760,7 +6768,7 @@ Sysval
@result{}
sysval
@result{}0
-esyscmd(`kill -9 $$')
+esyscmd([kill -9 $$])
@result{}
sysval
@result{}2304
--
2.31.1
Re: m4 on native Windows
On Wed, May 26, 2021 at 08:52:51AM -0500, Eric Blake wrote: > > +++ m4-tmp.432/m4-err 2021-05-14 02:31:09.296595600 +0200 > > @@ -1,2 +1,2 @@ > > -C:\cygwin64\home\bruno\m4-2021-05-13\build-mingw64\src\m4.exe:stdin:1: > > Warning: too few arguments to builtin `index' > > -C:\cygwin64\home\bruno\m4-2021-05-13\build-mingw64\src\m4.exe:stdin:3: > > Warning: excess arguments to builtin `index' ignored > > +m4.exe:stdin:1: Warning: too few arguments to builtin `index' > > +m4.exe:stdin:3: Warning: excess arguments to builtin `index' ignored > > Failures like this look like we just need to fix the sed script in > checks/check-them to properly filter the name output by native > Windows. I'm still trying to figure out how the names differ. Can you confirm what is output by: src/m4 --help | head -n1 in that setup? That output comes from usage() which uses program_name directly, while the other messages come from calling error_at_line() which uses program_invocation_name (on glibc) or getprogname() (otherwise), but as far as I can tell, unless we are running under libtool (where getprogname() strips off the lt- prefix), that should resolve to the same program_name as just printed in usage(). So what is going on differently in your native windows build that is changing what error_at_line() produces? At this point, I'm probably going to just go ahead and release 1.4.19 without trying to address the Windows testsuite failures. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
[m4-1.4.19] make error on Solaris 11.3 x86
Hello, Trying to install m4-1.4.19 on Solaris 11.3 x86. $ uname -a SunOS hidden 5.11 11.3 i86pc i386 i86pc $ gcc --version gcc (GCC) 10.3.0 $ ./configure CC=gcc (it mean CC='gcc -m32') $ make : CC stackvma.o In file included from stackvma.c:1476: /usr/include/sys/procfs.h:42:2: error: #error "Cannot use procfs in the large file compilation environment" 42 | #error "Cannot use procfs in the large file compilation environment" This did not occur in m4-1.4.18d. FYI: /usr/include/sys/procfs.h: 41 #if !defined(_LP64) && _FILE_OFFSET_BITS == 64 42 #error "Cannot use procfs in the large file compilation environment" 43 #endif Regards, --- Kiyoshi
