bug-m4
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: debugging M4 on AIX 5.3


From: Ralf Wildenhues
Subject: Re: debugging M4 on AIX 5.3
Date: Wed, 25 Aug 2010 23:25:03 +0200
User-agent: Mutt/1.5.20 (2010-04-22)

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-out        Wed Aug 25 19:05:46 2010
***************
*** 1,4 ****
! 5
! -1
  *** Unix *** nix ***
  
--- 1,4 ----
! 
! 
  *** Unix *** nix ***
  
@ ../doc/m4.texinfo:5688: Origin of test
../../m4/checks/164.regexp: stderr mismatch
*** m4-tmp.569356/m4-xerr       Wed Aug 25 19:05:46 2010
--- m4-tmp.569356/m4-err        Wed Aug 25 19:05:46 2010
***************
*** 0 ****
--- 1,3 ----
+ m4:stdin:1: bad regular expression: `\<[a-z]\w+': Memory exhausted
+ m4:stdin:2: bad regular expression: `\<Q\w*': Memory exhausted
+ m4:stdin:4: bad regular expression: `\<Q\w*': Memory exhausted
Checking ../../m4/checks/165.regexp
[... several more errors ...]
Failed checks were:
  ../../m4/checks/164.regexp:out ../../m4/checks/164.regexp:err 
../../m4/checks/173.patsubst:out ../../m4/checks/173.patsubst:err 
../../m4/checks/174.patsubst:out ../../m4/checks/174.patsubst:err 
../../m4/checks/231.improved_c:out ../../m4/checks/231.improved_c:err 
../../m4/checks/232.improved_c:out ../../m4/checks/232.improved_c:err
make: 1254-004 The error code from the last command is 1.


Bisect showed that if I go back to v1.4.14, the errors persist.

Bisect of gnulib/ subdir converges at
commit 723fc0b7b3a5d770a48945c1e1bca262a4c2615a
which is the "Use modern idiom for malloc() replacement." patch in
http://lists.gnu.org/archive/html/bug-gnulib/2010-06/msg00176.html
(all errors stem from this patch).

I see that confdefs.h before contains '#define malloc rpl_malloc'
and doesn't afterwards, but no other changes in the output section
of the respective config.log files.  Assuming that the stdlib.h header
logic is correct, my next best bet would be that some source doesn't
actually get to see the replaced header, but can't find any instances
of that right now, and it's late ...

Cheers,
Ralf



reply via email to

[Prev in Thread] Current Thread [Next in Thread]