Re: Small typo result in build error with MSVC

On 2025-06-05 06:21, Eric Blake wrote: Adding gnulib Bruno fixed that MSVC-related bug in Gnulib three weeks ago: https://cgit.git.savannah.gnu.org/cgit/gnulib.git/commit/?id=f7810929b1d35f1edcc0945df880adf6a6566602 and I just now propagated that into Savannah's m4 (branch-1.4). checking f

Re: \{n\} are not recognized as repetition counter in regular expressions.

On 2025-05-22 10:42, Eric Blake wrote: BSD has tried hard to make their m4 be a drop-in replacement enough that autoconf will use it instead of mandating GNU m4 Is this a real problem, though? I just now tried running Autoconf's 'configure' on FreeBSD 15, and FreeBSD 15's /usr/bin/m4 quickly f

Re: [PATCH] Update RE_SYNTAX_EMACS to include features used by GNU Emacs

On 2025-04-13 18:04, Paul Eggert wrote: Thanks; I installed the attached somewhat fancier patch into Gnulib. ... and then installed the attach further patch to fix a thinko in the previously-mentioned one.From f6d648a883676256894f5687cbceffb1f4209e3d Mon Sep 17 00:00:00 2001 From: Paul Eggert

Re: [PATCH] Update RE_SYNTAX_EMACS to include features used by GNU Emacs

Thanks; I installed the attached somewhat fancier patch into Gnulib.From efd5c380ff8062541d5fd98b050ecd3cb295917c Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 13 Apr 2025 18:01:08 -0700 Subject: [PATCH] regex: match current Emacs behavior * config/srclist.txt: Comment out regex.h

Re: bogus -Wsuggest-attribute=cold warning

On 2024-08-20 01:25, Bruno Haible wrote: why make things hard for users or CI jobs that use GCC 11, 12, or 13? I typically don't cruftify code merely to pacify older GCCs unless there's a demonstrated need, so let's hold off on that patch for now.

Re: bogus -Wnull-dereference warning

On 2024-08-19 18:32, Bruno Haible wrote: What can we do about it? I don't find it adequate to change the logic of the function 'make_room_for'. Usually we - disable a warning option completely if it generates nearly only false alarms, - disable a warning option for a certain compilat

Re: undefined-behavior obstack.c:139

On 2023-12-02 01:04, Bruno Haible wrote: On the contrary, I will try to find and eliminate such alarms. Please don't complicate and/or slow down shared Gnulib code just to pacify this particular false alarm from Clang. The obstack fix was fine, because it made obstack clearer and no slower. B

Re: undefined-behavior obstack.c:139

On 2023-12-01 12:36, Marc Nieper-Wißkirchen wrote: It may not be a false alarm in future versions of the compiler. If that happens, Gnulib (and lots of other software) won't work in those future versions. This is so unlikely that we needn't worry about it now.

Re: undefined-behavior obstack.c:139

On 2023-12-01 10:40, Bruno Haible wrote: Indeed, this sentence appears to forbid ((char *) NULL) + something. Yes. However, Gnulib code can still use ((char *) NULL) + something) because the Gnulib portability guidelines allow it. The issue with clang false positives is covered here: https

Re: M4 assembler error on compile

On 8/17/23 08:57, Eric Blake wrote: m4 is single-threaded, so an asynsafe-spin operation is not going to be vital to performance Gnulib has various options for omitting unnecessary locking code in single-threaded apps. If you have time, you might investigate why that is not happening for GNU

Re: Failing test: "test-posix_spawn-script". Race condition?

Thanks, I installed the attached, which I hope fixes the race condition in the Gnulib test.From a3efddb96f5f121b8a5bb1310dc82407546fd255 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Thu, 22 Dec 2022 21:19:34 -0800 Subject: [PATCH] posix_spawnp-tests: fix filename typo Problem reported for

Re: Assertion error when building in Debug mode with MSVC

report with them to save other people this kind of hassle. All the attached does is work around the /MDd bug.From 364c5ba2e40d17e98cc66021ef893e30a009068b Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Wed, 26 Jan 2022 09:33:03 -0800 Subject: [PATCH] close-stream: avoid crash on MSVC Debug mo

Re: Assertion error when building in Debug mode with MSVC

On 1/25/22 14:33, Julien Marrec wrote: Are the programs in question using the fclose module, either directly or indirectly? Well, simply doing `m4.exe --version` does exhibit the issue. For the module info we need to look at something other than that. Does your m4 source code contain the fi

Re: Assertion error when building in Debug mode with MSVC

On 1/25/22 08:13, Eric Blake wrote: it something that gnulib should work around by overriding fclose() to be guaranteed that it has an open fd? This is a bug that Gnulib's fclose module is already supposed to be working around. Are the programs in question using the fclose module, either dire

Re: m4-1.4.19 not C99 clean ?

ib on Savannah; please give it a try. With this patch, on my Solaris 10 sparc platform, Oracle Developer Studio 12.6 c99 issues a warning but it is not fatal, and that should be good enough. >From 3c42acd3b4e5941776bc45d529abf5687f9088ff Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 13

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

On 5/29/21 3:20 PM, Kiyoshi KANAZAWA wrote: Thank you, Paul. Everything good with your patch in 32 bit mode on Solaris. By the way, is this patch valid only in 32 bit mode (on Solaris) ? The patch should have no effect in 64-bit mode, which should work regardless of whether the patch is inst

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

from Gnulib? Should we be working to unify the two files, so that fixes to one also fix the other? From 87981840ebe68c9239625e5133b9fb86495163ad Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 29 May 2021 10:14:01 -0700 Subject: [PATCH] sigsegv: Port to Solaris 11 Problem reported by Kiyoshi KAN

Re: Latest M4 fails M4 checks

On 5/26/21 3:00 AM, Jeffrey Walton wrote: I could not find the release tarball. It looks like the link is stale. I just now generated a newer version, here: https://www.cs.ucla.edu/~eggert/m4-1.4.18d.4-f66e.tar.xz If you can't get developer tools running on your Mac, you can run the tools o

Re: stackovf.test fails on Solaris 11/sparc64

olaris SPARC working if it's easy. >From b4bb5c8ae79eebc3d5ec829b932c04df35881ef2 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 14 May 2021 22:48:20 -0700 Subject: [PATCH] c-stack: work around Solaris 11 bugs Problem reported by Bruno Haible in: https://lists.gnu.org/r/bug-gnulib/2021-05/msg00062.html * lib/c-stac

Re: Latest M4 fails M4 checks

In on 4/20/21 4:21 AM, Jeffrey Walton wrote: Maybe it's time to provide an updated M4. A 6 year old version of M4 that crashes is useless. It's long past time for a new GNU m4 to be published. I'm not surprised that GNU m4 w

Re: SIGSTKSZ is now a run-time variable

On 3/9/21 8:14 AM, shwaresyst via Libc-alpha wrote: The question becomes whether glibc is in violation of POSIX for having made the change, I don't see how that would be. Apps must define _SC_SIGSTKSZ_SOURCE or _GNU_SOURCE to get the new API, which means the apps do not want strict POSIX conf

Re: Fix m4 build with the newest gnulib

Thanks, I installed that in the 1.4 branch.

Re: Fix bootstrap failure with the newest gnulib

Thanks, I installed that and updated HACKING accordingly.

Re: "make distcheck" fails

On 7/11/20 4:15 AM, Bruno Haible wrote: 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 whethe

Re: [PATCH] Update after gnulib changed, v2

On 7/4/20 2:09 AM, Bruno Haible wrote: > A gnulib override is no longer needed. Please use this patch instead. Thanks, I installed that on Savannah in branch-1.4.

Re: test failure on FreeBSD 12.0

54f563da68a2ccc2b4 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 3 May 2020 18:32:57 -0700 Subject: [PATCH] Fix integer overflow bugs MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Problem reported by Bruno Haible in: https://lists.gnu.org/r/bug-

Re: test failure on FreeBSD 12.0

On 5/2/20 6:06 PM, Bruno Haible wrote: > The attached patch (for the 'branch-1.4' branch) fixes the issue. I think the actual bug lies elsewhere: m4 is written as if int32_t arithmetic wraps around silently, but that's not what C does. If I'm right, the bug is not in the FreeBSD C compiler, it's i

glibc 2.28 breaks the current m4 release

glibc 2.28 was released today. Unfortunately it breaks the build of m4-1.4.18, the current release of GNU m4. This bug was reported some time ago, here: https://lists.gnu.org/r/bug-gnulib/2018-03/msg0.html and fixed in Gnulib here: https://github.com/coreutils/gnulib/commit/4af4a4a71827c0b

Re: Problem with --version after compiling autoconf

On 05/30/2018 05:49 AM, Eric Blake wrote: more likely, all the way back to Nov 1993 when Francois Pinard introduced 0rNNN syntax into m4 1.1 (according to NEWS), although I cannot locate a tarball or version control of m4 that old. Some old GNU tarballs can be find at funet (Linux's first dist

Re: M4 tests fail when built with PGI compilers

On 02/06/2017 01:37 PM, Stewart, Adam James wrote: I tried applying your patch, and it looks like I got a bit further along, but `make check` still crashes with: CC test-stddef.o PGC-S-0045-Illegal field size (/blues/gpfs/home/software/spack-0.10.0/var/spack/stage/m4-1.4.18-zwtcbe4z66

Re: M4 tests fail when built with PGI compilers

On 01/31/2017 07:46 AM, Stewart, Adam James wrote: Yes, the warnings are annoying, but more importantly, `make check` doesn't pass for me. In fact, I'm not sure if it even gets to the testing phase. I think it crashes when trying to build the test suite. Your log file says all the M4 tests pa

Re: M4 tests fail when built with PGI compilers

On 01/30/2017 02:39 PM, Eric Blake wrote: I don't think test-intprops.c is compatible with the PGI compilers. Yes, test-intprops.c runs afoul of a problem in the PGI compiler. I can reproduce the problem in PGI 16.10 x86-64 by compiling this one-line program: short bar = -32768 <= 1

Re: compiler error on macOS Siera with GCC@6.2.1

tools installed. Thanks. git clone git://git.savannah.gnu.org/gnulib.git cd gnulib ./gnulib-tool --test sched From b1941d8e4f00a6dd8a0d12c5027499b7e0641a9a Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 24 Sep 2016 21:10:12 -0700 Subject: [PATCH] sched: port to GCC 6.2.1 on macOS Sierra MI

Re: compiler error on macOS Siera with GCC@6.2.1

On 09/23/2016 01:16 PM, Denis Davydov wrote: Would you please send the patch which applies to 1.4.17 Something like the attached, perhaps? --- configure 2013-09-21 23:38:28.0 -0700 +++ configure.new 2016-09-23 13:23:48.591707322 -0700 @@ -28724,7 +28724,7 @@ cat confdefs.h - <<_A

Re: compiler error on macOS Siera with GCC@6.2.1

On 09/23/2016 11:37 AM, Denis Davydov wrote: /usr/include/pthread_impl.h:32:18: error: missing binary operator before token "(" #if __has_feature(assume_nonnull) My guess is that sched.h isn't including sys/cdefs.h as it should on Darwin. The Darwin guys are not that big on supporting GCC, I

Re: Unable to install M4 1.4.17 using PGI 15.10 compilers

Bruno Haible wrote: Here's a proposed fix (in gnulib) (based on the predef list at https://sourceforge.net/p/predef/wiki/Compilers/): Thanks, I installed that.

Re: execute.c doesn't have fallback for systems without posix_spawn

Garrett Cooper wrote: configure:3527: loading site script /mnt/freebsd-ports//Templates/config.site ... | : ${ac_cv_header_spawn_h=yes} That's your problem. Your config.site file claims that there's a spawn.h, but there isn't. I stay away from config.site files myself, as they're trouble

Re: execute.c doesn't have fallback for systems without posix_spawn

My guess is that the FreeBSD 7 host has a stray /usr/include/spawn.h. There shouldn't be such a file, but if you try to upgrade to 8.x and then downgrade back to 7.x the file is left behind, and this messes up configuration. Try removing the stray file. Or, if you don't have root access, try

Re: [PATCH] fpending: fix regression on DragonFly BSD

Eric Blake wrote: > +#if !HAVE_DECL_FPENDING > size_t __fpending (FILE *) _GL_ATTRIBUTE_PURE; > Shouldn't that be HAVE_DECL___FPENDING?

Re: [ANN] m4-1.4.17 released [stable]

lt behavior for GCC nowadays? > maybe it's sufficient to change gl_COMPILER_OPTION_IF > to use AC_LINK_IFELSE instead of AC_COMPILE_IFELSE? Yes, thanks, that fixes the problem for me. I pushed this patch into gnulib: >From ab166f90fc84e0540e04836a626d2cc2afc91f77 Mon Sep 17 00:00:00 2001

Re: [ANN] m4-1.4.17 released [stable]

Eric Blake wrote: > is this > something where you can tackle the gnulib patch faster than I can? I can test something easily, yes, but I'm not sure what direction you're headed here.

Re: [ANN] m4-1.4.17 released [stable]

Eric Blake wrote: > On 09/22/2013 07:08 AM, Dagobert Michelsen wrote: > >> > >> > The latest release is no longer compilable with Sun Studio 12.3 compiler >> > as it >> > automatically uses GCC-specific flags: I don't observe this behavior on my host (Sun Studio 12.3, Solaris 10 sparc). I get

Re: [PATCH] make check failure on Tru64 Unix

On 03/10/2013 10:18 PM, Gary V. Vaughan wrote: > Any objections if I push the fix? No, thanks, that fix looks good to me.

Re: debugging M4 on AIX 5.3

On 08/21/2010 01:42 AM, Ralf Wildenhues wrote: Any hints as to what could make the tests fail when run as part of the M4 git tree and not otherwise? I don't envy you debugging that, but I have seen similar discrepancies for directory-style tests when my two source trees are in different file s

Re: stdin seekable failure

Eric Blake <[EMAIL PROTECTED]> writes: > Maybe the closeout module needs to be updated to worry about stdin as well > as stdout/stderr? Coreutils doesn't need that, as it doesn't have the problem. The two apps that I thought might have the problem solve it in a different way. 'head' bypasses st

Re: seekable stdin test failure on OS X

Eric Blake <[EMAIL PROTECTED]> writes: > +#elif HAVE___FPURGE > + /* __fpurge has no return value, so we must check errno. */ > + errno = 0; > + __fpurge (stream); > + if (errno) > +result = EOF; > + else > +{ > + result = 0; > + errno = e1; > +} This doesn't look righ

Re: seekable stdin test failure on OS X

Ben Pfaff <[EMAIL PROTECTED]> writes: > ISO C89 and C99 say that fflush(stdin) yields undefined behavior, > so I'm inclined to agree. It's more complicated than that, I'm afraid. Here's how I remember it; I haven't checked the actual documents. In the late 1980s the POSIX committee decided that

Re: seekable stdin test failure on OS X

"Gary V. Vaughan" <[EMAIL PROTECTED]> writes: > At worst we need an autoconf test to see whether fflush works on stdin, > but maybe all that is needed is to call fpurge when present, and > fallback to fflush otherwise? For what it's worth, on Solaris it's called __fpurge and is declared in (alon

Re: Building m4 on BSDI 4.0.1

Eric Blake <[EMAIL PROTECTED]> writes: > maybe it > is worth factoring out wchar.m4 into its own file and using that from all > other modules that use wchar_t or . Sounds like a lot of work for an operating system whose original supplier stopped support for many years ago. _

Re: Building m4 on BSDI 4.0.1

Eric Blake <[EMAIL PROTECTED]> writes: > BSD/OS 4.1 has a bug: and must be included before > - . */ > + . > + BSDI 4.0.1 has a bug: must be included before . */ > +# include That patch looks fine to me, except that the comment should say "BSD/OS" rather than "BSDI". The operating

Re: failure with HEAD: stdin seekable

Eric Blake <[EMAIL PROTECTED]> writes: > Perhaps we should add an accessor function that sets a static > variable in the closeout module, defaulting to 0, but that an > application can call to register any errno that it wants tracked (in > this case, after failing fflush, m4 would call the accesso

Re: Building m4 on BSDI 4.0.1

Chris McGuire <[EMAIL PROTECTED]> writes: > Wasn't the output of the build process that I sent along originally (showing > where it failed) an example? Sorry, no, as the output doesn't contain a test program. > if autoconf or configure could be tweaked in future > versions to apply what appears

Re: Building m4 on BSDI 4.0.1

Chris McGuire <[EMAIL PROTECTED]> writes: > I suspect that it is just a matter of configure not applying changes > it would make to BSD/OS 4.1 to my BSDI 4.0.1 box. Yes, most likely so. But to turn this vague idea into code that actually works for you, we need a concrete example of a simple C pr

Re: Building m4 on BSDI 4.0.1

Chris McGuire <[EMAIL PROTECTED]> writes: > To get m4 to build on my old BSDI 4.0.1 machine Hmm, that's software from a company (BSDI) that exists no longer. And the company's successor (Wind River Systems) discontinued support for BSD/OS at the end of 2004. Our usual rule is to not worry about

Re: Autoconf fails test 4 with m4-1.4.7a

Ralf Wildenhues <[EMAIL PROTECTED]> writes: > -configure.ac:19:TRACE1:foo bar:bar foo > +configure.ac:16:TRACE1:foo bar:bar foo Thanks for reporting that. I installed the following to pacify Autoconf 'make check' for now. I suppose we can install a better check later. 2

Re: obstack usage question

Eric Blake <[EMAIL PROTECTED]> writes: > Is the name okay? Is it worth adding to gnulib? Ideally I suppose it'd be added to glibc as well. This means patching the documentation, adding implementations for non-GCC compilers, etc. The name is fine with me. The style should use the same style as

Re: obstack usage question

Eric Blake <[EMAIL PROTECTED]> writes: > that double copy is bothering me; I would really like to reopen a > finished object for further growth without having to use temporary > storage. Any thoughts on the matter? Is this worth taking up with > glibc? Might be. How much would it change/slow d

Re: fpending issues on LSB: [ does not define size_t]

"Nelson H. F. Beebe" <[EMAIL PROTECTED]> writes: > > http://sourceforge.net/tracker/index.php?func=detail&aid=773937&group_id=1107&atid=101107 That's a bug report against the LSB spec, not against lsbcc. As I understand it, the bug was resolved by saying that the LSB spec defers to POSIX,

Re: fpending issues on LSB

"Nelson H. F. Beebe" <[EMAIL PROTECTED]> writes: > This is the same problem as before with size_t being used before > it is defined with this compiler. is one thing; it's not standardized. But is another. The compiler is seriously broken if does not define size_t. As I recall, the last main

Re: vasprintf on DEC

"Nelson H. F. Beebe" <[EMAIL PROTECTED]> writes: > It looks like I have to go looking again for a better free > implementation of snprintf(), sigh... That may be needed for other packages, but as far as I know it shouldn't be needed for gnulib-using packages like GNU M4; it should work fine on ho

Re: fpending issues on LSB

u verify whether it works for you? 2006-09-27 Paul Eggert <[EMAIL PROTECTED]> * lib/__fpending.h: Don't include unless HAVE_DECL___FPENDING. This avoids a bug with lsbcc, where it causes to cause a compile-time error. Problem reported by Nelson

Re: fpending issues on LSB

Eric Blake <[EMAIL PROTECTED]> writes: >> /opt/lsb/bin/lsbcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -c close-stream.c >> In file included from __fpending.h:25, >> from close-stream.c:27: >> /usr/include/stdio_ext.h:47: error: expected `=', `,', `;', `asm' or >> `__attribute__' b

Re: non-POSIX getopt() (Re: Updating FreeBSD port)

Mikhail Teterin <[EMAIL PROTECTED]> writes: > I wonder, how GNU's getopt implementation, where flags' arguments can be > optional, deals with the cases of such an option followed by something, that > begins with a dash itself: > > m4 -d -X It's the same way that (for example) 'pr -e' work

Re: Updating FreeBSD port

Mikhail Teterin <[EMAIL PROTECTED]> writes: > :-( Are there regex-patches currently waiting to be merged into GNU's libc? You can just do a diff between glibc and regex to find the list of patches. They aren't marshaled into a coherent set of small patches, which is the bottleneck. However, yo

Re: Updating FreeBSD port

Mikhail Teterin <[EMAIL PROTECTED]> writes: > However, there is not a single place anywhere in m4's code (outside of > getopt*.c), where optind is set to zero. Other gnulib-using programs do rely on that functionality, though, so we test for it in gnulib. It's not worth the configuration hassle

Re: Updating FreeBSD port

Mikhail Teterin <[EMAIL PROTECTED]> writes: > I see -- would you have a test-case, that detects this difference? No, but you can read the thread containing this message: http://lists.gnu.org/archive/html/bug-gnulib/2004-10/msg00171.html to see some of the issues here, and why gnulib getopt.m4 r

Re: Bug#385720: m4: INTERNAL ERROR: recursive push_string (fwd)

Eric Blake <[EMAIL PROTECTED]> writes: > In the meantime, perhaps Autoconf should document that > all autom4te input files should always end in newline. Nh. Let's just fix the bug in M4. It's clearly a bug. The GNU tradition is to handle arbitrary input files, and not to insist on "text" fi

new behavior in M4 1.4.5 breaks autoconf "make check"

Apparently a post-1.4.4b change to M4 changed one of its diagnostics? Anyway, the new diagnostic in M4 1.4.5 breaks Autoconf's "make check". I assume this change is permanent so I have installed the following into Autoconf. 2006-07-17 Paul Eggert <[EMAIL PROTECTED]>

M4 THANKS patches for my email address

[EMAIL PROTECTED] Noah Misch [EMAIL PROTECTED] -Paul Eggert[EMAIL PROTECTED] +Paul Eggert[EMAIL PROTECTED] Pete Chown [EMAIL PROTECTED] Pierre Gaumond [EMAIL PROTECTED] Pierre Mathieu [EMAIL PROTECTED

Re: m4_wrap behavior

My kneejerk suggestion is to implement m4wrap as POSIX requires, but to add another primitive (m4parw? :-) that works the way 1.4.4 m4wrap does. We can then ask people who prefer things the old-fashioned way to use m4parw. I'd rather not have the behavior depend on POSIXLY_CORRECT. POSIXLY_CORREC

Re: poor m4 hash performance

It changes M4 to use the same hash algorithm as gnulib/lib/hash.c. 2006-06-04 Paul Eggert <[EMAIL PROTECTED]> * src/m4.h (hash_table_size): Now size_t instead of int. * src/m4.c (hash_table_size): Likewise. (main): Adjust to this; use atol rather than atoi.

Re: poor m4 hash performance

[EMAIL PROTECTED] (Eric Blake) writes: > First, should autom4te experiment with changing the default hash > size, using the -H option? In principle that sounds reasonable, but please see below. > By default, m4 1.4.4 uses a 509 bucket hash table, with no dynamic > growth. Without a larger table

Re: GNU M4 1.4.3 exit status

John Gatewood Ham <[EMAIL PROTECTED]> writes: > Attached is the patch you requested. 'make check' still works. > Do you want me to add a test for this new behavior? Do you want > the info file to contain information about EXIT STATUS like the > man page does? I can add that if you wish. D

updated FSF contact address in m4/ltdl/m4/m4-gnulib.m4

I installed this obvious fix: 2005-07-07 Paul Eggert <[EMAIL PROTECTED]> * ltdl/m4/m4-gnulib.m4: Update FSF contact address. Somehow this file escaped the address updates on 2005-05-01. --- ltdl/m4/m4-gnulib.m44 May 2005 15:45:44 - 1.1 +++ ltdl

Re: [bug-gnulib] upgrade the regex module

Stepan Kasal <[EMAIL PROTECTED]> writes: > If I have spare time, I may prepare a patch to speed things up. To my mind the most pressing issue is to modify regex.m4 to also detect the problems in early editions of the glibc-2002 regex, and to substitute the new gnulib regex (i.e., the latest glibc

Re: [bug-gnulib] upgrade the regex module

Stepan Kasal <[EMAIL PROTECTED]> writes: > The new implementation, by Isamu Hasegawa from IBM Japan, has been accepted > to GNU libc several years ago. Well, "several years" is a bit of an overstatement. It was accepted in 2002. It is still not on my host (I'm running Debian stable). Initially

AC_PROG_LIBTOOL error should be fixed by GNU m4 1.4.2

Ludovic CourtÃs <[EMAIL PROTECTED]> writes: > This seems to be a bug in GNU M4 1.4.1 (see [1, 2, 3] for details). That bug should be fixed in GNU m4 1.4.2, available here: ftp://ftp.gnu.org/gnu/m4/m4-1.4.2.tar.gz (I write "should be" because I couldn't reproduce the problem on my Solaris 8 box

Re: AC_PROG_LIBTOOL error

d new release here: ftp://alpha.gnu.org/gnu/bison/m4-1.4.2.tar.gz ftp://alpha.gnu.org/gnu/bison/m4-1.4.2.tar.gz.sig Here are the changes embodied in this proposed release. If they look good to you, can you please copy it to <ftp://ftp.gnu.org/gnu/m4/>? Thanks. 2004-08-19

Re: GNU m4 patches for Bison, Autoconf?

(if you like it) publish it as ftp://ftp.gnu.org/gnu/m4/m4-1.4.1.tar.gz? Thanks. Here are the changes in this version, relative to m4 1.4. (Note that some of these changes are not in CVS m4) 2004-06-03 Paul Eggert <[EMAIL PROTECTED]> * Release 1.4.1. * configure.in (VERSION)

Re: RCS and m4 ported to nsr-tandem-nsk

> From: "Bates, Tom" <[EMAIL PROTECTED]> > Date: Tue, 17 Feb 2004 10:10:15 -0600 > +#ifdef __TANDEM > +#include > +#endif Thanks, but this is the first I've ever heard of __TANDEM or . Why is it needed here? Where is this stuff documented? I'd like to understand because I'd rather fix the unde

GNU m4 mktests.sh minor compatibility problem with POSIX 1003.1-2001

;). I'm using an experimental environment that insists on the new standard, so I tend to run into these problems before other people do. Here is a proposed patch for GNU m4. 2002-02-22 Paul Eggert <[EMAIL PROTECTED]> * examples/mktests.sh: Use `sed q', rather than `head -1&#