portability to BeOS

) 0xff) on Linux: #define __WEXITSTATUS(status) (((status) 0xff00) 8) #define WEXITSTATUS(status) __WEXITSTATUS(__WAIT_INT(status)) Here is the fix, ported to the current m4 CVS. 2006-04-30 Bruno Haible [EMAIL PROTECTED] * modules/m4.c (WEXITSTATUS): Provide fallback

update use of gnulib-tool

Hi, The way of invoking gnulib-tool has changed in the last few months: Parameters are now cached in a separate file gnulib-cache.m4 that is meant to be stored in CVS, and no longer provided in configure.ac. The steps to update to a new gnulib-tool are: 1) Run once the command $ gnulib-tool

Re: m4-1.4.4b problems

Eric Blake wrote: Ralf Wildenhues already identified frozen file format incompatibilities as an issue for autoconf, and added a patch to CVS autoconf that melts all files when bootstrapping autoconf (in other words, avoids using frozen files leftover from previous runs, in case the bootstrap

Re: fix gl_LOCK constraints

Eric Blake wrote: Unfortunately, this is now giving me the following when bootstrapping m4: during gnulib-tool update: Updating file ltdl/m4/lock.m4 (backup in ltdl/m4/lock.m4~) during autoreconf -fv autoreconf: running: autopoint --force ... Copying file ltdl/m4/lock.m4 ...

Re: [bug-gnulib] Updating FreeBSD port

Eric Blake wrote: . Although *snprintf code is compiled and linked into libm4, none of these functions make it into the m4 executable -- are the files obsolete? I'll take a look at that. It may be that it was only used by the code that I deleted when chopping out the usage

Re: m4/bootstrap

Ralf Wildenhues wrote: - Install Libtool. Fix your $automake_prefix/share/aclocal/dirlist file so that aclocal finds libtool's files, and $PATH so that it contains libtoolize. CVS Libtool has means in place to tell apart version inconsistencies. I'm not in favor of merging libtool

Re: seekable stdin test failure on OS X

Hi Eric, The 'e1' variable is not needed, I think. No standard specifies that errno must be preserved across function calls: - C99 does not mention 'errno' in the description of fflush, - POSIX does, and says in http://www.opengroup.org/susv3/functions/xsh_chap02_03.html that The value

Re: seekable stdin test failure on OS X

Eric Blake wrote: 2007-04-09 Eric Blake [EMAIL PROTECTED] * modules/fflush: New file. I'm completing the module description like this (for documentation purposes): 2007-04-12 Bruno Haible [EMAIL PROTECTED] * modules/fflush (Include): Mention stdio.h. * modules

Re: obstack_printf

Eric Blake wrote: obstack_printf is glibc specific, and not part of the gnulib obstack module. Is there interest in supporting obstack_printf alongside the vasnprintf family? Yes. Since glibc has it, and it can be implemented in a portable way, it is welcome if gnulib provides a substitute.

Re: stdin seekable failure

Eric Blake wrote: However, the fflush module is still broken for mingw when reading files in text mode that have plain LF line endings. It appears that mingw's ftell tries to compensate for \r\n line endings in text mode, but does the compensation even when there is just a plain \n line

Re: stdin seekable failure

Eric Blake wrote: The workaround would be to see if lseek returns a non-negative number; and if so, read the internals of the FILE to see how many bytes remain in the read buffer (the default buffer size is 4k); then since the file is seekable, temporarily swap the fd into O_BINARY mode,

Re: mingw lseek bug

Brian Dessent wrote: However, I'm not sure on mingw how to detect whether an fd is open on a regular file vs. a pipe. Any ideas? Check out ser-mingw.c from gdb, they have a fair amount of MinGW pipe/fd handling code there, e.g. static int fd_is_pipe (int fd) { if (PeekNamedPipe

Re: mingw lseek bug

Eric Blake wrote: I just noticed that lseek on mingw returns 0 instead of -1 on pipes. Which means that gnulib's fflush module thinks the pipe is seekable, and loses data in the pipe instead of behaving as a no-op as it should in trying to reposition the pipe's location. Indeed, lseek on

Re: M4 1.4.9b testsuite failure

Andreas Schwab wrote: The problem is that the test is bogus. The position of one of the exponent bits does not say anything about the position of the SNAN bit. For example, the Motorola double extended format has 16 bits of padding between the exponent and the mantissa. Even with out padding

M4 1.4.9b testsuite failure on HP-UX

On HP-UX 11.23 / ia64: test-lseek.c:76: assertion failed ./test-lseek.sh[14]: 3086 Abort(coredump) FAIL: test-lseek.sh The reason is in case 2: although you tell the shell to close stdin and stdout, when the test-lseek.c runs, it has open file descriptors 0 and 1. (This can be verified with

Re: M4 1.4.9b testsuite failure

Andreas Schwab wrote: Bruno Haible [EMAIL PROTECTED] writes: union u { unsigned int word[4]; long double value; } x = { { 0x, 0x4001, 0x, 0x } }; This is not a valid number. The integer bit _must_ be 1 for a valid NaN or Infinity. The Intel IA-64

Re: m4-1.4.10 compile error: unsigned reference to decimal_point_char

stackovf.o ../lib/libm4.a ../lib/libm4.a(vasnprintf.o): In function `vasnprintf': vasnprintf.c:(.text+0x3690): undefined reference to `decimal_point_char' Whee. I apologize for this bug. This should fix it: 2007-07-13 Bruno Haible [EMAIL PROTECTED] * lib/vasnprintf.c (decimal_point_char

Re: [EMAIL PROTECTED]: Re: CVS commit: pkgsrc/devel/m4]

Joerg Sonnenberger [EMAIL PROTECTED] wrote: They want to force replacement functions for fseeko down our throat when configure detected that fflush for r streams doesn't work. This breaks obviously on DragonFly, but I don't think this test should be allowed at all. *sigh* I hate gnulib.

Re: [EMAIL PROTECTED]: Re: CVS commit: pkgsrc/devel/m4]

. If someone wants to submit a patch handling the __FILE_public, please do gnulib-tool --create-testdir --dir=... fbufmode fflush fpurge freadable \ freading fseeko fseterr ftello fwritable fwriting to see which files need to be adjusted for this special situation. Bruno 2007-07-27 Bruno Haible

Re: [EMAIL PROTECTED]: Re: CVS commit: pkgsrc/devel/m4]

Joerg Sonnenberger wrote: Be careful, this breaks the intention. If you reset the flag, you also have to keep overriding fseek/fseeko, because it will set use the optimisation again. Indeed, with the proposed patch and the system's fseek/fseeko, I get a test failure on MacOS X: File offset

Re: [EMAIL PROTECTED]: Re: CVS commit: pkgsrc/devel/m4]

Joerg Sonnenberger wrote: Indeed, with the proposed patch and the system's fseek/fseeko, I get a test failure on MacOS X: File offset is wrong after fseek: 17. FAIL: test-fflush But it works with the more agressive approach? Yes, with the proposed patch and the overridden

Re: [EMAIL PROTECTED]: Re: CVS commit: pkgsrc/devel/m4]

Eric Blake wrote: I think it is worth applying, after addressing any nits. Applied, with the change that you mentioned: + stream-_flags = ~__SOPT; + stream-_flags |= __SNPT; Is it more efficient to write it like this? stream-_flags = (stream-_flags ~__SOPT) | __SNPT; gcc

Re: Configure problem when compiling with -D_FORTIFY_SOURCE

Alf mel wrote: While trying out the lastest offerings in Glibc (2.6.1) and GCC (4.2.1) via the DIY-Linux project (www.diy-linux-.org), I encountered the following error in the configure script when compiled with CFLAGS=-O2 -fstack-protector -D_FORTIFY_SOURCE=2. Here is what I

Re: m4-1.4.10 segfault with x86_64 during ./configure when checking whether printf supports infinite 'long double' arguments

Bruno Haible [EMAIL PROTECTED] * m4/printf.m4 (gl_PRINTF_INFINITE_LONG_DOUBLE): Use GL_NOCRASH to avoid a segmentation fault of the configure test on x86_64 systems. *** m4/printf.m4.orig 2007-12-17 10:18:35.0 +0100 --- m4/printf.m42007-12-17 10:17:58.0

Re: [m4-1.4.11] build feedback

Hi Eric, Eric Blake wrote: The failures are all in gnulib portability code, and don't appear to immediately impact m4 behavior (the gnulib replacements are more general than what m4 uses them for). Meanwhile, can you please rerun with 'make -k' to get the full set of failures? You would not

Re: Working os/2 configuratie

Eric Blake wrote: More failures without line numbers: Killed by SIGFPE FAIL: test-frexp.exe Killed by SIGFPE FAIL: test-frexpl.exe Killed by SIGFPE FAIL: test-printf-frexp.exe Killed by SIGFPE FAIL: test-printf-frexpl.exe Killed by SIGFPE FAIL: test-signbit.exe ... Bruno's areas of

Re: [m4-1.4.11] build feedback

-vasprintf-posix Seems isnanl doesn't work but only if you use gcc instead of cc. This is due to the autoconf test. 2008-04-12 Bruno Haible [EMAIL PROTECTED] * m4/isnanf.m4 (gl_ISNANF_WORKS): Add a test for a special NaN. Reported by Nelson H. F. Beebe [EMAIL PROTECTED]. *** m4

Re: m4-1.4.11: assert failure in two self tests on NetBSD

Hi, Thomas Klausner reported: | m4-1.4.11 fails two selftests on NetBSD-4.99.48/amd64. | The first one is in test-frexpl: | | # gdb test-frexpl test-frexpl.core | GNU gdb 6.5 | Copyright (C) 2006 Free Software Foundation, Inc. ... | Core was generated by `test-frexpl'. | Program

Re: m4-1.4.11: assert failure in two self tests on NetBSD

__GNUC__ makes the failure go away. Bingo! I'm applying this: 2008-04-12 Bruno Haible [EMAIL PROTECTED] * lib/fpucw.h: Enable the definitions also for x86_64. Needed for NetBSD/x86_64. Reported by Thomas Klausner [EMAIL PROTECTED]. --- lib/fpucw.h.orig2008-04-13 02

Re: [m4-1.4.11] build feedback

Tom G. Christensen wrote: I see the same test failure when building m4-1.4.11 on Irix 5.3 and 6.2 regardless of compiler used. Irix 6.2 with MIPSpro 7.3.0 or GCC 4.3.0 (Indigo2 R10K): test-vasprintf-posix.c:1309: assertion failed /bin/ksh[9]: 10221 Abort(coredump) FAIL:

Re: [m4-1.4.11] build feedback

Tom G. Christensen wrote: - Does 1.0 / -0.0 0 evaluate to true or false? - Does 1.0L / -0.0L 0 evaluate to true or false? true true Thanks. That's different from what I got on some IRIX 6.5 machine, but it's consistent with what you and Nelson see. - At

Re: os2

Elbert Pol wrote: U:/test-fflush: No such file or directory. An error message No such file or directory tell you to look for the right file name. Probably it has a .exe suffix? Btw: I have to run Gdb after i try to port the software? No. gdb 6.4 is very good for x86 platforms; even gdb 5.x

Re: fpurge.c error when building m4 1.4.11

system, then report this to bug-gnulib. | make[3]: *** [fpurge.o] Error 1 OK, I'm adding tentative support for Linux libc5. The predefine test could be defined __linux__ defined __ELF__ !defined __UCLIBC__ or __GNU_LIBRARY__ == 1 I'm using the latter, since it's simpler. 2008-04-16 Bruno

Re: fpurge.c error when building m4 1.4.11

Hello Alain, Thanks for the report. It means the extended stdio functions tests passed and are therefore ok. Fine! Another problem came in: | gcc -I. -g -O2 -c memchr2.c | memchr2.c:86: two `l's in integer constant | make[3]: *** [memchr2.o] Error 1 | make[3]: Leaving directory

Re: extended stdio API on DragonFly

| One of the main DragonFly developers provided a patch, see | http://leaf.dragonflybsd.org/mailarchive/users/2008-04/msg00044.html Thanks. Matthew Dillon added the __sreadahead function just a few days ago. It is equivalent to gnulib's freadahead function, except that freadahead returns 0 if

Re: linkage problem with m4 1.4.11 on AIX 6.1

Hello, Rainer Tammer wrote: | on AIX 6.1 two objects are missing from the libm4.a. | | ... | Making all in src | gmake[2]: Entering directory | `/opt/freeware/src/packages/BUILD/m4-1.4.11/src' | gcc -std=gnu99 -g -O2 -o m4 m4.o builtin.o debug.o eval.o format.o | freeze.o input.o

Re: extended stdio API on DragonFly

There was no answer from the DragonFly BSD developers. So I'm adding the DragonFly BSD support without their system support. 2008-04-26 Bruno Haible [EMAIL PROTECTED] Add tentative support for DragonFly BSD. * lib/stdio-impl.h: Add macros for DragonFly BSD. * lib

Re: lib/regex_internal.h on 1.4.11

, it would be clear that the problem is with the compiler and not with the library functions. FAIL: test-fseeko.sh test-ftello.c:92: assertion failed ./test-ftello.sh[3]: 15850 Abort(coredump) FAIL: test-ftello.sh An stdio bug. But it is not likely to hit 'm4' users. Bruno 2008-07-31 Bruno Haible

Re: diversion failure [was: snapshot in preparation for m4 1.4.12]

Eric Blake wrote: In looking at this further, it looks like line 4179 of vasnprintf.c should _not_ count precision as a prefix if prec_ourselves is nonzero. Yes. Now that you say it, it's obvious that the code in line 4179 should be in sync with the code in line 4077. Without the patch to

Re: 'long double' support on MacOS X and BSD platforms

Hello Nelson, Builds of m4-1.4.12 fail on Apple Mac OS X 10.x PowerPC systems with this error: gcc -std=gnu99 -I. -I../lib -I. -I. -I.. -I./.. -I../lib -I./../lib -I/usr/local/include -g -O2 -MT test-frexpl.o -MD -MP -MF .deps/test-frexpl.Tpo -c -o test-frexpl.o

Re: abort() on Windows 2008 Server

Eric Blake wrote: int sigfillset (sigset_t *set) { ! *set = ((2U (NSIG - 1)) - 1) !#ifdef SIGABRT_COMPAT ! ~(1U SIGABRT_COMPAT) !#endif !; However, I'm not the biggest fan of #ifdef inside a statement. Maybe a helper macro would make this read a bit

Re: Fwd: Building m4 fails under Interix-3.5

this system simply does not have SA_NODEFER. Just ignore it. Most signal handlers will behave equally well with SA_NODEFER than without. 2008-10-23 Bruno Haible [EMAIL PROTECTED] Define a dummy SA_NODEFER macro on Interix. * lib/signal.in.h (SA_NODEFER): Define fallback

Re: final snapshot in preparation for m4 1.4.12

Eric Blake wrote on 2008-09-29: On Irix 5.3 it skips test-cstack2.sh because it wants libsigsegv for full c-stack functionality and I did not test with that (Irix really needs libsigsegv 2.7 which is not yet released). That's Bruno's call It's OK that the test-c-stack2.sh test is skipped

Re: Bus error

Thomas J. Duck wrote: I have installed m4-1.4.12 on my Mac OS X 10.4 system. 'Make check' results in the error below. If there is any further information you need, please let me know. --Tom Checking ./stackovf.test Stack soft limit set to 300K Failure - m4 aborted unexpectedly

Re: Bus error

Eric Blake wrote: maybe swapping the order will help, where I install the SIGBUS handler first, and then c_stack_action can optionally install an alternate handler on platforms where it is needed for stack overflow? Yes, I was going to propose this too. Bruno

Re: 'make test' error

Eric Blake wrote: In other words, it seems like we should consider modifying the contract of c-stack to state that the application should not modify SIGBUS handlers. Yes, right. I'm adding this comment: 2008-12-06 Bruno Haible [EMAIL PROTECTED] * lib/c-stack.h (c_stack_action

Re: test-c-stack2.sh failure on HP-UX

: PASS: test-c-stack.sh cannot tell stack overflow from crash; consider installing libsigsegv SKIP: test-c-stack2.sh 2009-01-24 Bruno Haible br...@clisp.org * lib/c-stack.c (segv_handler): If !HAVE_XSI_STACK_OVERFLOW_HEURISTIC, set signo = 0 also if info-si_code = 0. Needed on HP-UX

Re: HP-UX 10.20 format failure (was: snapshot 3 in preparation for 1.4.13)

Gary V. Vaughan wrote: All pass except this one: ... cc -I. -I../lib -I. -I. -I.. -I./.. -I../lib -I./../lib -I../intl +O2 -Ae -z +Ofltacc +ESlit +DAportable +Oentrysched +Odataprefetch +Onolimit -c test-vasprintf-posix.c test-vasprintf-posix.c:2804: assertion failed FAIL:

Re: HP-UX 10.20 format failure (was: snapshot 3 in preparation for 1.4.13)

for these precisions. I'm applying this workaround. 2009-02-26 Bruno Haible br...@clisp.org Work around *printf bug with %g directive and 0.0 on HP-UX 10.20. * m4/printf.m4 (gl_PRINTF_INFINITE): Also test for %g output of -0.0. Reported by Gary V. Vaughan g...@gnu.org. --- m4

Re: Compiler error of m4-1.4.13 on AIX using xlc

Eric Blake wrote: CC strtod.o strtod.c, line 155.17: 1506-045 (S) Undeclared identifier HUGE_VAL. strtod.c, line 170.17: 1506-232 (I) Divisor for modulus or division operator cannot be zero. #include_next ///usr/vac/include/math.h -- wrong: must use /usr/include The problem was

Re: errors building m4 on interix/sfu/sua

Eric Blake wrote: gnulib can work around missing ESTALE, but we would need to port errno_h.m4 to detect interix's situation Done as follows: 2009-06-17 Bruno Haible br...@clisp.org Define missing ESTALE on Interix 3.5. * lib/errno.in.h (ESTALE): Assign a value if missing

Re: Intel C++ compiler for Linux 11.1 doesn't build m4 1.4.13 on NetBSD

fpos_t might or might become a struct, the use of fpos_t is better avoided. I'm therefore applything this (which currently is a no-op). 2009-12-19 Bruno Haible br...@clisp.org fflush: tweak * lib/fflush.c (update_fpos_cache): Don't use fpos_t on Cygwin. * lib/fseeko.c

Re: m4 1.4.14 esyscmd problems on FreeBSD

this fix. 2010-03-02 Bruno Haible br...@clisp.org spawn: Don't override the system defined values on FreeBSD 8. * lib/spawn.in.h (POSIX_SPAWN_RESETIDS, POSIX_SPAWN_SETPGROUP, POSIX_SPAWN_SETSIGDEF, POSIX_SPAWN_SETSIGMASK, POSIX_SPAWN_SETSCHEDPARAM

Re: next m4 snapshot

Rainer Tammer wrote: All checks are OK on AIX 5.3. All checks are OK on AIX 6.1 All checks are OK on AIX 7BETA Nice! Thanks for testing. Which gnulib patch fixed the regex problem on AIX ?? It was apparently this one:

Re: test-readlink failure on GNU/Linux

Ludovic Courtès asked: Gnulib has already been relaxed to work around the Linux violation of POSIX, Are you referring to commit 68483ca35c0dbd347744327b1020b2e4215454f1? He was referring to commit dc44690985e727ac2ef5af783a495a369223ab69

Re: [GNU m4 1.4.16] testsuite: test-setlocale2.sh failed

Hi, Solaris 11 x86_64, out-of-box; please, find attached testsuite log. ... FAIL: test-setlocale2.sh (exit: 1) == Chinese_Taiwan.65001: unknown locale setlocale did not fail for explicit (null) This is supposed to be already fixed in gnulib [1].

Re: Automake-installed auxiliary scripts can get silently out-of-date after an Automake upgrade

Eric Blake wrote: Any idea for a simple solution to this problem? Aren't there timestamps in the auxiliary scripts for a reason? If a script is updated as part of a new automake release, can't automake insert some sanity checks to see if the currently-installed scripts have too old of a

Re: Unable to install M4 1.4.17 using PGI 15.10 compilers

e's a proposed fix (in gnulib) (based on the predef list at https://sourceforge.net/p/predef/wiki/Compilers/): >From cf4e1225e443180a5a838846d3f9b12baa376605 Mon Sep 17 00:00:00 2001 From: Bruno Haible <br...@clisp.org> Date: Sat, 5 Mar 2016 01:35:03 +0100 Subject: [PATCH] extern-inline: po

Re: Cannot compile m4 1.4.18 with clang 4.0

> Thompson, KT wrote: > > As reported at https://github.com/LLNL/spack/issues/4883, there appears to > > be a problem compiling m4 (version 1.4.18) on Linux with LLVM clang 4.0. > > The error is: > > > > ... > > CC m4.o > > CC builtin.o > > CC debug.o > > CC

Re: Test failure in GNU M4 1.4.18 with musl libc

Eric Blake wrote: > Both of these failed tests come from gnulib (added in cc); I'm not sure > if they have been fixed in the meantime They have been fixed in gnulib on 2018-02-24. Bruno

The state of the 1.4.x branch

Hi all, The 'branch-1.4' of the git repository https://git.savannah.gnu.org/gitweb/?p=m4.git;a=shortlog;h=refs/heads/branch-1.4 uses a git submodule that connects it to a particular version of gnulib, from 2016. This makes it impossible to use the normal checkout or the m4-1.4.18 release for

build failure on OpenBSD 6.5

Hi, On OpenBSD 6.5/x86_64, the newest release m4-1.4.18 exhibits a "make check" failure of 'test-localename': FAIL: test-localename = ../../tests/test-localename.c:183: assertion 'strcmp (name, "fr_FR.UTF-8") == 0' failed Abort trap (core dumped) FAIL test-localename (exit

build failure on NetBSD 9.0

Hi, On NetBSD 9.0/x86_64, the newest release m4-1.4.18 exhibits a "make check" failure: CC test-localename.o ../../tests/test-localename.c: In function 'test_locale_name': ../../tests/test-localename.c:74:3: warning: implicit declaration of function 'uselocale'; did you mean

build failure on Solaris 11.4

Hi, On Solaris 11.4/x86_64, the newest release m4-1.4.18 exhibits a "make check" failure of 'test-localename': FAIL: test-localename = ../../tests/test-localename.c:183: assertion 'strcmp (name, "fr_FR.UTF-8") == 0' failed ../../build-aux/test-driver: line 107: 14852:

Re: Bug

[CCing bug-m4] Hi, Rahmad Alamsyah Nazaruddin wrote: > I got this issue '#error "please port gnulib freadhead.c to your platform! > Look at the definition of fflush, fread, ungetc on your system' > How can i fix this ? I fail install on M4 Thank you for reporting this.

test failure on AIX

rocess to read data written to a pipe. hi bye 0 The attached patch fixes it. >From 922bd937edae734435a449ef90647939be775bc7 Mon Sep 17 00:00:00 2001 From: Bruno Haible Date: Sun, 3 May 2020 13:49:26 +0200 Subject: [PATCH 3/3] Fix failure of test 006.command_li on AIX 7.2. * doc/m4.texi (Command li

Re: test failure on FreeBSD 12.0

12.0. That is, after this patch, my previous patch is still needed. Bruno >From 8160ff54537e454e5653d6bc7e735c28f2b99c10 Mon Sep 17 00:00:00 2001 From: Bruno Haible Date: Sun, 3 May 2020 11:49:00 +0200 Subject: [PATCH] Don't assume that signed integer arithmetic wraps around like unsigned.

Re: [m4] The source code has been broken for years

Michael Witten wrote: > It appears that for years, m4's source code has been broken; > > * The last commit to the git repo was this: > > commit d69fa5284851b2b7aac25ffac638b6b379994db5 > AuthorDate: Sat Dec 31 14:56:15 2016 -0600 > CommitDate: Mon Jan 9 13:55:30 2017 -0600

Re: make[3]: *** [Makefile:1910: freadahead.o] Error 1

[CCing bug-m4] z___qf wrote: > > freadahead.c: In function 'freadahead': > freadahead.c:92:3: error: #error "Please port gnulib freadahead.c to your > platform! Look at the definition of fflush, fread, ungetc on your system, > then report this to bug-gnulib." >92 | #error "Please port

Fix bootstrap failure with the newest gnulib

00:00:00 2001 From: Bruno Haible Date: Sun, 23 Aug 2020 01:33:08 +0200 Subject: [PATCH] build: Fix bootstrap failure with the newest gnulib. * configure.ac: Require Autoconf 2.64 at least. --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.a

Re: [PATCH] Update after gnulib changed, v2

Paul Eggert wrote: > Thanks, I installed that on Savannah in branch-1.4. Thank you. Especially also for the "build: update gnulib submodule to latest" commit, that fixes a build failure on glibc systems that was reported multiple times.[1] Bruno [1]

Re: [PATCH] Update after gnulib changed, v2

A gnulib override is no longer needed. Please use this patch instead. >From 2639bdc228b00f7847f825063d9299d8d9733be0 Mon Sep 17 00:00:00 2001 From: Bruno Haible Date: Sat, 4 Jul 2020 10:29:44 +0200 Subject: [PATCH] Update after gnulib changed. * src/output.c (m4_tmpfile, m4_tmpopen): Upd

Re: "make distcheck" fails

Hi Paul, > > I can reproduce it on an Ubuntu 16.04.x machine: > > > m4.c:166:1: error: function might be candidate for attribute 'pure' if it > > is known to return normally [-Werror=suggest-attribute=pure] > > fault_handler (int signo) > > ^ > > ... > > > It is not clear to me whether

"make distcheck" fails

10.1.0/gcc/Common-Function-Attributes.html >From dd0238c24a64fdbb35fe6fd2310425d5a07f38e6 Mon Sep 17 00:00:00 2001 From: Bruno Haible Date: Sat, 11 Jul 2020 13:12:59 +0200 Subject: [PATCH] Fix "make distcheck" failure on Ubuntu 16.04. * configure.ac: Don't use the warning option -Wsugg

Fix m4 build with the newest gnulib

modules 'execute' and 'spawn-pipe' (see gnulib/NEWS). This patch fixes it. Can you please apply it? Thanks. >From c6f796b82d5ef7fdd30d3a3aa17cf4dbc06d32ad Mon Sep 17 00:00:00 2001 From: Bruno Haible Date: Sun, 13 Dec 2020 01:46:46 +0100 Subject: [PATCH] Update after gnulib changed. * src/builti

format is locale aware

Hi, After building m4-1.4.19 on DragonFly BSD 6.0, with LC_ALL=fr_FR.UTF-8, "make check" shows a test failure: Checking ../../checks/180.format @ ../doc/m4.texi:6066: Origin of test ../../checks/180.format: stdout mismatch --- m4-tmp.452851/m4-xout 2021-06-08 03:26:41.805343000 +0200 +++

Re: format is locale aware

Eric Blake wrote: > > 2) Why do I see the test 180 fail on DragonFly BSD but not on a glibc > > system? In both cases, I have LC_ALL set to fr_FR.UTF-8, and this locale > > exists (verified with 'locale -a'). > > May be due to differences in strtod() parsing on those platforms, or > something we

Re: Discrepancy in regards to program_name output

Sören Tempel wrote: > > tl;dr If argv[0] is a full path (e.g. because of qemu-user usage), > > many tests will fail because --help uses argv[0] while error messages > > use basename(argv[0]). Yes, that's the cause. Good analysis. > > Not sure how to resolve this, if getprogname is expected to

Re: m4 on 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 > > It is: > Usage: C:\cygwin64\home\bruno\m4-2021-05-13\build-mingw64\src\m4.exe > [OPTION]... [FILE]... In fact, it depends on the program that invokes src/m4. The

Re: format is locale aware

Hi Eric, > However, as previous versions of m4 were NOT locale-aware, enabling > locale support on what was supposed to be a minor release feels > awkward Yes; it can break some existing scripts that invoke m4. > > If no, the fix would be in main.c: Add a > > setlocale (LC_NUMERIC, "C"); > >

posix_spawn, posix_spawnp: Fix build error on Minix 3.3

, ^ --- This patch fixes it. 2021-05-13 Bruno Haible posix_spawn, posix_spawnp: Fix build error on Minix 3.3. * m4/posix_spawn.m4 (gl_POSIX_SPAWN_BODY): If posix_spawn does not exist but is declared, set

m4 on native Windows

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

stackovf.test fails on Solaris 11/sparc64

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

m4 1.4.18b testing results

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

Avoid undefined behaviour when parsing the number -2147483648

ability problems. OK to push? >From 981f4617c6362a22eee20247c170e760812e5b68 Mon Sep 17 00:00:00 2001 From: Bruno Haible Date: Sun, 9 May 2021 01:37:36 +0200 Subject: [PATCH] Avoid undefined behaviour when parsing the number -2147483648. * src/eval.c (eval_lex): Use an unsigned variable for accum

test failure on Haiku

On Haiku (32-bit), compiling m4-1.4.18b+fixes works fine, but one of the tests fails: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Checking ../../checks/198.sysval @ ../doc/m4.texi:6749: Origin of test ../../checks/198.sysval: stdout mismatch --- m4-tmp.10743/m4-xout

Fix build error when libintl is installed

_in_path() in findprog.o -> xmalloc() -> xalloc_die() -> libintl_gettext() This patch to gnulib fixes it. In m4, you'll need to update to the current gnulib. 2021-05-08 Bruno Haible Fix build error when libintl is installed. * modules/posix_spawn_file_actions

free tests: Avoid test failure on glibc < 2.15

have no way to do anything about it. 2021-05-09 Bruno Haible free tests: Avoid test failure on glibc < 2.15. * tests/test-free.c (main): Skip the hairy test on glibc < 2.15. diff --git a/tests/test-free.c b/tests/test-free.c index e651f18..53f1085 100644 --- a/test

Enable more single-thread optimizations in gnulib code

ons can be enabled. This patch - enables these single-threading optimizations, - by doing so, gets rid of the warnings in regex.c, - causes no test failures. OK to push? >From 611fa6cd92671318b22e70f931db695a58ecdaf3 Mon Sep 17 00:00:00 2001 From: Bruno Haible Date: Thu, 13 May 2021 10:

Re: [m4-1.4.19] make error on Solaris 11.3 x86

Paul Eggert wrote: > Thanks for reporting the bug. Please try the attached patch, which I > installed into Gnulib. Thanks, Paul, that's the correct fix. Apologies: I had tested the 'sigsegv' module mostly on its own, and tested it together with GNU m4 only on 4 or 5 platforms. Bruno

[sr #110502] 1.4.19: test suite is failing

Update of sr #110502 (project m4): Status:None => Need Info ___ Follow-up Comment #4: Please tell us how to reproduce the issue: * which operating system? * which values of CC, CPPFLAGS,

Re: m4 on native Windows

Hi Eric, > > > +++ 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' > > >

Re: [PATCH] tests: Skip signal detection on Haiku

Eric Blake wrote: > 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. Thank you. I confirm that now, on Haiku, all m4 tests pass. (A few gnulib tests fail, that apparently

[sr #110502] 1.4.19: test suite is failing

Update of sr #110502 (project m4): Priority: 5 - Normal => 3 - Low ___ Follow-up Comment #6: Your CFLAGS and LDFLAGS contain exotic options that are not available on machines I have access to.

Re: SIGSTKSZ is now a run-time variable

Eric Blake wrote: > I can open a defect against POSIX if we decide that is needed, but want > some consensus first on whether it is glibc's change that went too far, > or POSIX's requirements that are too restrictive for what glibc wants to do. Thanks for opening the discussion, Eric. Here are a

m4 domain disappeared from TP

Hi Benno, The weekly continuous integration build of GNU m4 failed this week, because it cannot access http://translationproject.org/latest/m4/ . Also, in https://translationproject.org/domain/index.html the domain 'm4' is no longer present, and in https://translationproject.org/extra/matrix.html

Re: SIGSTKSZ is now a run-time variable

Hi, Carol Bouchard wrote in : > A change that was introduced is the > #define SIGSTKSZ is no longer a statically defined variable. It's value can > only be determined at run time. > > # define SIGSTKSZ sysconf (_SC_SIGSTKSZ) This

Re: m4 domain disappeared from TP

Hi Benno, > I removed the m4 domain from the TP (archiving it) because m4 hasn't made > an announcement to the TP for more than ten years, AND I've looked into > the latest tarball (1.4.18) and none of the PO files from the TP are there. > If the PO files are not being used, it is a waste of

Re: m4 domain disappeared from TP

Benno Schulenberg wrote: > Okay. I've downloaded the latest snapshot, ran ./bootstrap --skip-po, > ran ./configure and make dist, and looked at the resulting m4.pot file. > > It has no resemblance to the m4-1.4o.pot file that we had at the TP: > almost all strings are different. Also, in

Re: m4-1.4.19 not C99 clean ?

Dennis Clarke wrote: > MiscXS.c: loadable library and perl binaries are mismatched (got handshake > key e18, needed df8) > gmake[2]: *** [Makefile:1979: m4.info] Error 1 MiscXS.c is a file in GNU texinfo. The error message is therefore related to your texinfo installation. See also [1].

  1   2   >