Compiling a recent m4 snapshot on native Windows:
- The "make" step works fine.
- The "make check" step fails. Find attached the log.
Essentially, there are failures around syscmd, and error messages display
the absolute file name of the 'm4.exe' executable.
Bruno
GEN public-submodule-
The newest m4 snapshots don't pass all their tests on Solaris 11.3/sparc64:
stackovf.test fails.
This happens also when GNU libsigsegv is installed and --with-libsigsegv-prefix
is given, because the c-stack.m4 autoconf test now insists in ignoring
GNU libsigsegv when it thinks that the Solaris heu
I tested m4-1.4.18b and subsequent tarballs (with fixes included)
on some platforms. Aside from
- the problems reported here and in bug-gnulib,
- a couple of gnulib unit tests that fail on some of the less
important platforms,
the build went fine and all unit tests passed on:
Linux x86_64
On 5/14/21 5:07 PM, Bruno Haible wrote:
I won't spend any more time on fixing this Solaris-only code — when we
have code that works on all platforms in GNU libsigsegv.
At first I fixed this by having c-stack simply defer to libsigsegv if
installed, but I found that this didn't work on gcc211 i