a few glitches in CVS HEAD m4

Hi there, This is just a few random observations perusing CVS HEAD m4, for the benefit of Gary when he returns to work on it. :) - I get a build failure of src/getopt.c on GNU/Linux glibc-2.3.2: | In file included from ../m4/src/getopt.c:80: | ../m4/src/getopt_int.h:26: error: conflicting types

Re: cygwin build problem with m4 HEAD

Hi Eric, [ Ccing bug-m4 again ] * Eric Blake wrote on Fri, Sep 09, 2005 at 02:06:12PM CEST: > According to Ralf Wildenhues on 9/9/2005 1:31 AM: > >>>I notice that it is attempting to link against /usr/lib/libltdl.dll.a, > >>>which comes from libtool 1.5.18,

Re: cygwin build problem with m4 HEAD

Hi Eric, * Eric Blake wrote on Fri, Sep 02, 2005 at 03:29:58PM CEST: > > I don't know if this is a bug in m4 or in libtool, but with the absolute > latest CVS autoconf, automake, and libtool installed into /usr/local, and > latest CVS m4 plus my patch to fix bootstrap > (http://article.gmane.org/

Re: libtool --ltdl vs. autoreconf

Hi Eric, * Eric Blake wrote on Tue, May 09, 2006 at 02:04:23PM CEST: > > As promised here, > http://lists.gnu.org/archive/html/m4-patches/2006-05/msg5.html, I > noticed that m4 bootstrap invokes libtoolize --ltdl prior to autoreconf, > which reinvokes libtoolize without --ltdl. This seems li

Re: libtool --ltdl vs. autoreconf

Hi Eric, > * Eric Blake wrote on Tue, May 09, 2006 at 02:04:23PM CEST: > > > > As promised here, > > http://lists.gnu.org/archive/html/m4-patches/2006-05/msg5.html, I > > noticed that m4 bootstrap invokes libtoolize --ltdl prior to autoreconf, > > which reinvokes libtoolize without --ltdl. T

Re: poor m4 hash performance

* Eric Blake wrote on Sun, Jun 04, 2006 at 05:40:05AM CEST: > > m4: lookup mode 0 called 229730 times, 557880 compares, 348729 misses, > 4672624 bytes Am I reading this correctly in that 2.4 compares are done per lookup? If yes, then it looks to me like the hash is doing perfectly fine. (But I h

Re: poor m4 hash performance

[ removing autoconf list -- please Cc: me on replies ] * Eric Blake wrote on Mon, Jun 05, 2006 at 12:09:07AM CEST: > According to Ralf Wildenhues on 6/4/2006 2:56 PM: > > * Eric Blake wrote on Sun, Jun 04, 2006 at 05:40:05AM CEST: > >> m4: lookup mode 0 called 229730 time

Re: libtool --ltdl vs. autoreconf

[ moving from autoconf to -patches ] * Ralf Wildenhues wrote on Thu, May 25, 2006 at 06:39:38PM CEST: > > * Eric Blake wrote on Tue, May 09, 2006 at 02:04:23PM CEST: > > > > > > http://lists.gnu.org/archive/html/m4-patches/2006-05/msg5.html, > > > I

Re: changing compiler flags at configure time

Hi Eric, * Eric Blake wrote on Mon, Jun 12, 2006 at 03:12:33PM CEST: > > CVS head of m4 currently has a macro, ltdl/m4/debug.m4, that attempts to > alter compile-time flags according to whether --enable-debug is passed to > ./configure. However, it uses AC_DISABLE_SHARED and AC_ENABLE_SHARED > i

Re: m4_wrap behavior

* Paul Eggert wrote on Tue, Jun 13, 2006 at 07:08:24PM CEST: > 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. Yes.

Re: m4_wrap behavior

Hello Stepan, * Stepan Kasal wrote on Tue, Jun 13, 2006 at 10:46:31PM CEST: > > The obvious consequence is that Autoconf <= 2.60 won't work with GNU > m4 2.0. > Luckily, there is no risk of installing a broken version of autoconf; > the build will break, since autoconf.as is a m4sh script. This

Re: Feature request: setting env vars for binary wrappers

* Gary V. Vaughan wrote on Thu, Jun 15, 2006 at 02:00:28PM CEST: > Ralf Wildenhues wrote: > > * Gary V. Vaughan wrote on Thu, Jun 15, 2006 at 12:57:42PM CEST: > >> Ralf Wildenhues wrote: > > >> ${1+"$@"} 2>/tmp/m4-$$ > > > > This i

Re: testsuite.dir location

Hello Eric, * Eric Blake wrote on Fri, Jun 16, 2006 at 04:16:05PM CEST: > > Is it intentional that running testsuite outputs testsuite.log and > testsuite.dir in $PWD? Yes. That's what a hundred useful programs (cc, for example) do by default with output. (Programs writing to "`dirname $inputf

Autoconf <-> CVS M4 interactions

[ Cc:ing bug-m4 mostly as FYI ] M4 upgrade scenario: - You are working on Autoconf; the build tree has the same --prefix as an earlier version of Autoconf that is already installed there. - The earlier Autoconf version used M4 1.4.x as underlying work horse. - Now (sometime in the future) you a

Re: Autoconf <-> CVS M4 interactions

Hi Eric, * Eric Blake wrote on Fri, Jun 16, 2006 at 09:36:41PM CEST: > > > > M4 upgrade scenario: > Indeed, I will not allow CVS M4 to be released as m4-2.0 until I am > satisfied that this very scenario works without regressions Good. Well, my testing then has two results: one bug in Autoconf

Re: Autoconf <-> CVS M4 interactions

* Ralf Wildenhues wrote on Fri, Jun 16, 2006 at 07:13:58PM CEST: > > [...] lib/m4sugar/m4sh.m4f has not been built at the time > autoconf.as is built, so autom4te will prefer the installed (but old!) > frozen m4sh.m4f. FYI, I have installed the first patch as below, making it clear

Re: Autoconf release

* Eric Blake wrote on Mon, Jun 19, 2006 at 02:30:12PM CEST: > According to Paul Eggert on 6/19/2006 12:33 AM: > > > > One possibility for m4wrap is to do nothing until after 2.60 is out. > > I.e., if m4 2.0 isn't expected to be out soon, we can fix m4wrap > > issues in Autoconf 2.61. > > I'll put

Re: m4-1.4.4b problems

be unable to understand > (since it only parses format version 1). In short, downgrading m4 > potentially invalidates all frozen files created with the newer version. > Ralf Wildenhues already identified frozen file format incompatibilities as > an issue for autoconf, Right: there are incompat

HEAD: defn test fails

CVS M4 fails test 60 for me on GNU/Linux x86_64: What else do you need to know? (Or maybe this is a known failure and I just didn't see it?) Cheers, please Cc: me on replies, Ralf # -*- compilation -*- 60. generated.at:514: testing ... ../../m4/tests/../m4/doc/m4.texin

Re: depcomp deficiency [was: m4-1.4.7 build feedback]

Hello Nelson, Eric, Thanks for the bug report. * Eric Blake wrote on Wed, Sep 27, 2006 at 04:21:27AM CEST: > According to Nelson H. F. Beebe on 9/26/2006 8:51 AM: > > Machinetype:Sun W40z (4 CPUs, 2400 MHz AMD64 Opteron, 8GB RAM); > > FreeBSD 6.1-RELEASE #0 > > Configure environment:

Re: depcomp deficiency [was: m4-1.4.7 build feedback]

Hello Nelson, * Nelson H. F. Beebe wrote on Wed, Sep 27, 2006 at 03:23:45PM CEST: > > The BSD folks are a different religion from the GNU folks, so > conflicts in software interfaces are to be expected. Not really. The Automake dependency tracking code tries quite hard to work with any compiler

Re: depcomp deficiency [was: m4-1.4.7 build feedback]

FYI, I've proposed a patch to this; guess it's better to announce it here, too: http://lists.gnu.org/archive/html/automake-patches/2006-09/msg00032.html Cheers, Ralf ___ Bug-m4 mailing list Bug-m4@gnu.org http://lists.gnu.org/mailman/listinfo/bug-m4

Re: [GNU M4 1.9a] testsuite: 52 59 60 61 62 failed

* Ralf Wildenhues wrote on Sat, Oct 14, 2006 at 03:05:30PM CEST: > For some days, the testsuite has been failing again. Whoops. With a new build tree, only 52 fails. Sorry about the noise. (Goes off to look whether that was just tough luck or some missing dependency...) Cheers, R

Re: [GNU M4 1.9a] testsuite: 52 59 60 61 62 failed

ees. > A while ago, I moved the build location of modtest.la from modules to > tests for the sake of 'make installcheck', Indeed, a `rm modules/modtest.la' fixes this failure. How about this? (We do similar in Libtool for a couple of things.) Cheers, Ralf 200

Autoconf fails test 4 with m4-1.4.7a

With current Autoconf HEAD (and 2.60, FWIW), and M4 branch-1_4, I get a failure of Autoconf's test 4 on my GNU/Linux system. Cheers, Ralf # -*- compilation -*- 4. tools.at:126: testing ... ../../autoconf/tests/tools.at:169: autoconf --force -t TRACE1 -t TRACE2 --- -

Autoconf fails tests 24 and 26 with M4 branch-1_4 now

I'm seeing further destabilization in the Autoconf/M4 combo. My increased focus on testing this combination is because: - there was an announcement that the next Autoconf release may be released soon, - due to Stepan's recent changes to Autoconf, it practically now *requires* at least M4 1.4.7

Re: m4/bootstrap

Hello Bruno, Eric, * Eric Blake wrote on Thu, Nov 02, 2006 at 06:55:53AM CET: > According to Bruno Haible on 11/1/2006 1:07 PM: > > > > When I invoke "./bootstrap -p no" in the savannah m4 CVS (HEAD), I get > > finally [...] > > autoreconf: running: autoconf --force > > configure:5222: error: po

Re: m4/bootstrap

* Bruno Haible wrote on Thu, Nov 02, 2006 at 02:20:31PM CET: > > # This script bootstraps a CVS checkout of GNU M4 by correctly > # calling out to parts of the GNU Build Platform. Currently this > ! # requires GNU Autoconf 2.60, GNU Automake 1.9.6, GNU Libtool 1.5.22 IIRC CVS HEAD M4 does

Re: m4/bootstrap

* Eric Blake wrote on Thu, Nov 02, 2006 at 02:41:41PM CET: > According to Ralf Wildenhues on 11/2/2006 6:33 AM: > > By the way, M4's bootstrap script could just as well invoke > > libtoolize --ltdl=ltdl --install --copy --force > At one point, it did. But I wonder

Re: m4/bootstrap

* Eric Blake wrote on Thu, Nov 02, 2006 at 03:20:22PM CET: > According to Ralf Wildenhues on 11/2/2006 6:56 AM: > > > >> At one point, it did. But I wondered why we were invoking libtoolize > >> prior to autoreconf, when autoreconf reinvokes libtoolize, and patches &

[sr #101730] add a link to further information to web

Follow-up Comment #2, sr #101730 (project m4): The FSF directory page for GNU M4 is http://directory.fsf.org/GNU/gnum4.html and the gnu.org M4 page is the first I get in a directory search for M4. Eric, you can help to keep the directory up to date by sending a patch against the template. Here'

failure with HEAD: stdin seekable

Hi Eric, all, This new test fails for me on GNU/Linux x86 (Debian testing). Cheers, Ralf # -*- compilation -*- 63. others.at:458: testing ... ../../m4/tests/others.at:466: m4 -b -d < in.m4 ../../m4/tests/others.at:473: (m4; cat) < in.m4 --- - 2006-12-15 11:20:25.79

Re: failure with HEAD: stdin seekable

* Eric Blake wrote on Sun, Dec 17, 2006 at 05:21:02AM CET: > > * src/main.c (main): Check for errors when closing stdin. > * modules/m4.c (m4exit): Missed part of previous patch: flush > stdin before a successful exit. Thanks, the stdin seekable test is skipped now, but also the

Re: cygwin vs. --disable-static

Old old thread: * Eric Blake wrote on Sat, Oct 07, 2006 at 07:04:13PM CEST: > According to Gary V. Vaughan on 10/5/2006 1:24 AM: > > On 3 Oct 2006, at 13:44, Eric Blake wrote: > >>> Is there some way to keep > >>> the temporary .libs

Re: undefined macro

Hello Ben, * [EMAIL PROTECTED] wrote on Thu, Mar 29, 2007 at 05:37:20AM CEST: > > Jason kindly gave me a login on the system that was exhibiting > the problem. I think I tracked down the problem. My analysis > follows. I'm sorry that you had to do it for this known bug. I guess I should have

HEAD: inclusion order wrong for input.c

Hello there, CVS HEAD m4 currently gives me this warning on GNU/Linux: | ../m4/m4/input.c:483: warning: implicit declaration of function 'strnlen' which indicates that config.h wasn't included before string.h. I'm a bit at a loss to see right away how the structurually correct fix for M4 would l

Re: HEAD: inclusion order wrong for input.c

* Gary V. Vaughan wrote on Mon, Apr 02, 2007 at 02:32:45PM CEST: > Thanks for the report. Although I don't get this warning, I have cleaned > up the remaining warnings that I did see on OS X. Thanks, looking better now. I do get these warnings now, with -Wall: ../m4/m4/macro.c: In function 'e

Re: HEAD: inclusion order wrong for input.c

* Gary V. Vaughan wrote on Mon, Apr 02, 2007 at 08:28:56PM CEST: > On 2 Apr 2007, at 18:45, Ralf Wildenhues wrote: > >* Gary V. Vaughan wrote on Mon, Apr 02, 2007 at 02:32:45PM CEST: > >> Thanks for the report. Although I don't get this warning, I have > >>cleane

Re: HEAD: inclusion order wrong for input.c

Hi Eric, * Eric Blake wrote on Tue, Apr 03, 2007 at 06:10:08AM CEST: > According to Ralf Wildenhues on 4/2/2007 11:45 AM: > > > > and also, I still get two test failures on GNU/Linux x86_64. > > Care to share the testsuite.log? Certainly. Here you go. Pretty recent ve

Re: HEAD: inclusion order wrong for input.c

* Eric Blake wrote on Wed, Apr 04, 2007 at 03:21:46PM CEST: > > Are you interested in installing GMP to further test the mpeval module (5 of > the 6 skips)? Those tests (26 73 124 125 136) pass with GMP. > Also, can you show me tests/testsuite.dir/068/testsuite.log > so I can see why 'stdin seek

Re: HEAD: inclusion order wrong for input.c

Hi Eric, * Eric Blake wrote on Tue, Apr 10, 2007 at 03:24:15PM CEST: > According to Ralf Wildenhues on 4/6/2007 5:07 AM: > > ../../m4/tests/others.at:478: (sed -ne 1q; cat) < in.m4 > > + sed -ne 1q > > + cat > > stdout: > > + set +x > > ../../m4/tests

Re: stdout full

; than 1k text is printed to /dev/full. > Reported by Ralf Wildenhues. With this, HEAD's testsuite passes again on GNU/Linux x86_64, with expected failures: 9: Renamesyms collisions (macros.at:514) 96: Defn (generated.at:736) and skipping: 68: st

Re: stdin seekable failure

> (main): Use close_stdin instead of close_stdout. > Reported by Ralf Wildenhues. ___ Bug-m4 mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-m4

test-memmem takes waaay too long

Hello, and a Happy New Year, quoting memmem.m4: AC_CACHE_CHECK([whether memmem works], [gl_cv_func_memmem_works], [AC_RUN_IFELSE([AC_LANG_PROGRAM([#include ], [return !memmem ("a", 1, NULL, 0);])], [gl_cv_func_memmem_works=yes], [gl_cv_func_memmem_works=no], [d

Re: 'set -u' and $SHELL in makefiles [was: GNU M4]

Hello, I don't either know what the root cause of your problem is, but it seems to me it could not hurt if checks/Makefile.in used the same shell and $(MAKE) initialization as did all the automake-generated Makefiles. Cheers, Ralf 2008-01-31 Ralf Wildenhues <[EMAIL P

generating testsuite in bootstrap?

Hello, is it worthwhile to generate m4/tests/testsuite from within bootstrap, so that then, ./configure && make all install does not need the autotools? Cheers, Ralf ___ Bug-m4 mailing list Bug-m4@gnu.org http://lists.gnu.org/mailman/listinfo/bug-m

distcheck fails test 056

Hi Eric, I'm seeing a test failure of test 056 on branch-1_4 with --enable-changeword; valgrind warns with or without the switch though: Checking ../../checks/056.indir @ ../doc/m4.texinfo:2440: Origin of test ../../checks/056.indir: stderr mismatch --- m4-tmp.19265/m4-xerr2008-02-18 10:5

branch-1_4 cannot build Autoconf 2.59 any more

Hello Eric, I think an inadvertent backward incompatibility has been introduced. Example failure: ./autom4te --language=autotest -I ../../autoconf-2.59/tests suite.at -o testsuite.tmp ../../autoconf-2.59/tests/local.at:370: error: m4_init: unbalanced m4_divert_push: ../../autoconf-2.59/tests/loc

Re: branch-1_4 cannot build Autoconf 2.59 any more

Hi Eric, * Eric Blake wrote on Mon, Mar 24, 2008 at 01:47:21AM CET: > > So, for example, you could submit a patch to gcc to add this to > configure.ac (or one of the files it includes), prior to calling AC_INIT: > > # As long as we aren't ready to upgrade to autoconf 2.60, > # make sure that newer

Re: branch-1_4 cannot build Autoconf 2.59 any more

* Eric Blake wrote on Mon, Mar 24, 2008 at 01:08:14PM CET: > According to Ralf Wildenhues on 3/24/2008 5:43 AM: > |> # As long as we aren't ready to upgrade to autoconf 2.60, > |> # make sure that newer M4 will still use LIFO order: > With the typo corrected, I get no di

Re: branch-1_4 cannot build Autoconf 2.59 any more

* Eric Blake wrote on Mon, Mar 24, 2008 at 01:54:16PM CET: > According to Eric Blake on 3/24/2008 6:08 AM: > | | This isn't sufficient > | > | With the typo corrected, I get no difference on your simple example. > > I had been wavering for some time, but you have finally given me the > clinching ar

m4-1.4.x fails to build git Autoconf for some x (was: branch-1_4 cannot build Autoconf 2.59 any more)

On Mon, Mar 24, 2008 at 07:10:24AM -0600, Eric Blake wrote: > > I'll try looking into the MinGW failure, but I'm not sure how long it > will take me to reproduce it (I don't normally build in MinGW; Here's some more data. I installed MinGW's m4-1.4.7 which works fine. It has this diff over vanil

Re: m4-1.4.x fails to build git Autoconf for some x (was: branch-1_4 cannot build Autoconf 2.59 any more)

Hi Keith, thanks for chiming in (I hoped you would ;-) * Keith Marshall wrote on Mon, Mar 24, 2008 at 09:18:00PM CET: > On Monday 24 March 2008 16:51, Ralf Wildenhues wrote: > > Here's some more data. I installed MinGW's m4-1.4.7 which works > > fine. It has this diff

Re: m4-1.4.x fails to build git Autoconf for some x

* Eric Blake wrote on Tue, Mar 25, 2008 at 01:55:56PM CET: > | just killing \r in autom4te.in leads to > | > | C:\msys\1.0\home\ralf\local\bin\m4.exe: premature end of frozen file > > Where did you kill \r? From the frozen file itself (if so, how did it get > there in the first place, if m4 is re

Re: snapshot in preparation for m4 1.4.12

Hi Eric, * Eric Blake wrote on Thu, Aug 07, 2008 at 03:37:47PM CEST: > Therefore I would appreciate some feedback before making the 1.4.12 > release (if you encounter a testsuite failure in the m4 suite, please > rerun with 'make -k check' before reporting it, so that the gnulib > testsuite is als

Re: sed on binary files

Hi Eric, * Eric Blake wrote on Thu, Oct 02, 2008 at 04:51:58AM CEST: > > Is there any portable way to process files that contain NUL bytes? tr? If you only need to compare for equality, then use cmp. > The Solaris man > pages mention that /usr/xpg4/bin/tr can handle NUL bytes, but not > /usr/b

Re: sed on binary files

* Eric Blake wrote on Thu, Oct 02, 2008 at 02:46:38PM CEST: > > I'll add a blurb to the autoconf manual on sed mentioning that it cannot > be used on binary files (although Posix already says that), Isn't that obvious? I mean, of all classic unix text-related tools, only very few operate on non-

verbose testsuite output contains 1M newlines

Hello Eric, running make check-local TESTSUITEFLAGS=-v on M4 (git master) produces lots of output on GNU/Linux/bash. More precisely, the AT_CHECK in builtins.at:470 causes 1024*1024 newlines to be output, and I think there are more instances later. Can this easily be avoided? Hmm, maybe this

Re: verbose testsuite output contains 1M newlines

* Eric Blake wrote on Sun, Nov 23, 2008 at 03:56:49PM CET: > According to Ralf Wildenhues on 11/23/2008 6:23 AM: > > running > > make check-local TESTSUITEFLAGS=-v > > > > on M4 (git master) produces lots of output on GNU/Linux/bash. > Hmm, this particular test

branch-1.6 distcheck failure

Hi Eric, branch-1.6 currently fails distcheck for me with this at the very end: make[2]: Leaving directory `/tmp/build/m4-1.5.89a.101-d7ae/_build' rm -f config.status config.cache config.log configure.lineno config.status.lineno rm -f Makefile ERROR: files left in build directory after distclean:

Re: verbose testsuite output contains 1M newlines

Hi Eric, * Eric Blake wrote on Mon, Apr 13, 2009 at 03:14:21PM CEST: > According to Ralf Wildenhues on 11/23/2008 9:37 AM: > > Maybe we can have AT_CHECK modifiers or sister macros that allow to > > specify that some output may not be suitable for the screen or the log > >

testsuite failures with current git master M4

Hi Eric, seeing a couple of failures with current git master M4: Cheers, Ralf ## -- ## ## GNU M4 1.9a.502-64df-dirty test suite. ## ## -- ## testsuite: command line was: $ ../m4/tests/testsuite -C tests ## --- ##

git master should use gnulib module snprintf

Hi Eric, git master M4 uses snprintf in m4/output.c but does not use the snprintf module from gnulib. This leads to a link error on Tru64/OSF1: autom4te_perllibdir='../../autoconf'/lib AUTOM4TE_CFG='../lib/autom4te.cfg' ../bin/autom4te -B '..

Re: testsuite failures with current git master M4

* Eric Blake wrote on Sat, Jun 13, 2009 at 06:41:20AM CEST: > According to Ralf Wildenhues on 6/12/2009 4:26 AM: > > seeing a couple of failures with current git master M4: > > > > +++ /tmp/m4/build/tests/testsuite.dir/at-groups/40/stdout 2009-06-12 > > 12:23:32.

Re: testsuite failures with current git master M4

* Ralf Wildenhues wrote on Sat, Jun 13, 2009 at 11:21:04AM CEST: > * Eric Blake wrote on Sat, Jun 13, 2009 at 06:41:20AM CEST: > > According to Ralf Wildenhues on 6/12/2009 4:26 AM: > > > seeing a couple of failures with current git master M4: > > > -m4: unrecogn

branch-1.4 distcheck failure due to -Wstack-protector

Hi Eric, distcheck fails for me with current branch-1.4 on GNU/Linux/x86_64, gcc-4.2.4: gcc -std=gnu99-I../../lib -I../lib -Wall -W -Wformat-y2k -Wformat-security -Winit-self -Wmissing-include-dirs -Wswitch-default -Wunused -Wunknown-pragmas -Wstrict-aliasing -Wstrict-overflow -Wfloat-equa

Re: [GNU Autoconf 2.65] testsuite: 229 failed

* Gene Spafford wrote on Sat, Feb 27, 2010 at 03:37:42AM CET: > I use ksh > As part of the .profile, it runs the terminal reset sequence each login > I don't see this as bad behavior > > The ,kshrc file sets the prompt and does no other output. > > I don't see either of these as setting up a ba

Re: next m4 snapshot

[ dropping bug-gnulib, not sure if that's a mistake ] Hi Eric, * Eric Blake wrote on Fri, Jul 30, 2010 at 04:23:16PM CEST: > Now fixed in gnulib, and therefore in my current m4 snapshot: > > Grab m4-1.4.14.6-76d1 from http://people.redhat.com/eblake/m4/ I tried that on AIX 5.3, see failures bel

debugging M4 on AIX 5.3

I'm trying to debug the recent regression of git branch-1.4 M4 over M4 1.4.14 on AIX. First the gnulib stuff. Notes: - 2 gnulib test failures in M4: test-strtod, test-rmdir. I inserted one fprintf in test-strtod.c, for the "0xp" input asserting over 'ptr == input + 1': const char input[] =

Re: debugging M4 on AIX 5.3

* Eric Blake wrote on Mon, Aug 23, 2010 at 04:04:54PM CEST: > On 08/21/2010 02:42 AM, Ralf Wildenhues wrote: > >- 2 gnulib test failures in M4: test-strtod, test-rmdir. > > > >I inserted one fprintf in test-strtod.c, for the "0xp" input asserting > >over '

Re: debugging M4 on AIX 5.3

Continuing with M4 branch-1.4 failures on AIX 5.3: @ ../doc/m4.texinfo:5688: Origin of test ../../m4/checks/164.regexp: stdout mismatch *** m4-tmp.569356/m4-xout Wed Aug 25 19:05:46 2010 --- m4-tmp.569356/m4-outWed Aug 25 19:05:46 2010 *** *** 1,4 ! 5 ! -1 *** Unix

Fix malloc, calloc, realloc (was: debugging M4 on AIX 5.3)

* Ralf Wildenhues wrote on Wed, Aug 25, 2010 at 11:25:03PM CEST: > Continuing with M4 branch-1.4 failures on AIX 5.3: [...] > *** m4-tmp.569356/m4-xerr Wed Aug 25 19:05:46 2010 > --- m4-tmp.569356/m4-errWed Aug 25 19:05:46 2010 > *** > *** 0 > -

Re: Fix malloc, calloc, realloc (was: debugging M4 on AIX 5.3)

* Ralf Wildenhues wrote on Sat, Aug 28, 2010 at 09:40:34AM CEST: > The patch series makes M4's own testsuite pass, but in the meantime, > something else broke again so I'm still not completely done. Never mind, that was PEBKAC. M4 1.4.14.6-76d1-dirty works with git gnulib and my

Re: Fix malloc, calloc, realloc

Hello, * Eric Blake wrote on Sun, Aug 29, 2010 at 12:12:27AM CEST: > On 08/28/2010 01:55 AM, Ralf Wildenhues wrote: > >M4 1.4.14.6-76d1-dirty works with git > >gnulib and my patch series on AIX 5.3! Yay. > > Thanks again, very much, for tracking that down, Ralf. I will b

Re: next m4 snapshot

* Eric Blake wrote on Mon, Aug 30, 2010 at 09:55:02PM CEST: > >Here's the latest snapshot tarball, if nothing goes terribly wrong, then > >I hope to get 1.4.15 out the door this week. > http://people.redhat.com/eblake/m4/m4-1.4.14.9-edf2d.tar.gz Passes check on AIX 5.3. Cheers, Ralf

Re: bug in autoconf-2.64

Hello, * Peter O'Gorman wrote on Wed, Feb 23, 2011 at 04:50:32AM CET: > Unless I did it wrong (entirely possible) - > 76d1c49b8056aaf3f1046ba19c6dea6eb6aecb78 is the first bad commit - I can confirm the issue, but my bisect ended at 5e763da323f3927159b6c151f186569a9929ddbe instead. (You need to u

Re: bug in autoconf-2.64

* Ralf Wildenhues wrote on Wed, Feb 23, 2011 at 09:08:07PM CET: > I can confirm the issue, but my bisect ended at > 5e763da323f3927159b6c151f186569a9929ddbe instead. > I'm starting bisect over the gnulib update in above commit now, > which ranges from c0ebdfe226c38c72db7c194411

Re: bug in autoconf-2.64

* Mike Stump wrote on Thu, Feb 24, 2011 at 12:06:07AM CET: > On Feb 23, 2011, at 1:37 PM, Eric Blake wrote: > > Are you on a machine with SSE4.2 instructions? > > Core 2 Duo. darwin10 (aka SnowLeopard). No glibc. Here no SSE4.2 either. In an up to date build tree of the commit that exposes the

Re: bug in autoconf-2.64

[ this is http://thread.gmane.org/gmane.comp.sysutils.autoconf.bugs/7834 from http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01480.html adding bug-gnulib; followups can elide bug-autoconf ] * Ralf Wildenhues wrote on Thu, Feb 24, 2011 at 07:24:35AM CET: > IOW, it looks like the replacement c

Re: bug in autoconf-2.64

* Eric Blake wrote on Sun, Feb 27, 2011 at 12:52:22AM CET: > > * Ralf Wildenhues wrote on Wed, Feb 23, 2011 at 09:08:07PM CET: > >> I can confirm the issue, but my bisect ended at > >> 5e763da323f3927159b6c151f186569a9929ddbe instead. > > Thankfully, 'git