Andreas Schwab | 6 Mar 15:22 2008
Picon

make_argv_ref_token: Assertion `!chain->next && chain->type == CHAIN_ARGV && !chain->u.u_a.skip_last' failed.

m4 1.4.10b fails on the attached input when called via autoconf.

m4 --nesting-limit=1024 --include=/usr/share/autoconf --debug=aflq --fatal-warning
--debugfile=autom4te.cache/traces.0t --trace=AC_CANONICAL_BUILD --trace=AC_CANONICAL_HOST
--trace=AC_CANONICAL_SYSTEM --trace=AC_CANONICAL_TARGET --trace=AC_CONFIG_AUX_DIR
--trace=AC_CONFIG_FILES --trace=AC_CONFIG_HEADERS --trace=AC_CONFIG_LIBOBJ_DIR
--trace=AC_CONFIG_LINKS --trace=AC_CONFIG_SUBDIRS --trace=AC_DEFINE_TRACE_LITERAL
--trace=AC_FC_FREEFORM --trace=AC_FC_SRCEXT --trace=AC_INIT --trace=AC_LIBSOURCE
--trace=AC_PROG_LIBTOOL --trace=AC_REQUIRE_AUX_FILE --trace=AC_SUBST --trace=AC_SUBST_TRACE
--trace=AH_OUTPUT --trace=AM_AUTOMAKE_VERSION --trace=AM_CONDITIONAL
--trace=AM_ENABLE_MULTILIB --trace=AM_GNU_GETTEXT --trace=AM_GNU_GETTEXT_INTL_SUBDIR
--trace=AM_INIT_AUTOMAKE --trace=AM_MAINTAINER_MODE --trace=AM_PROG_CC_C_O
--trace=AM_PROG_CXX_C_O --trace=AM_PROG_F77_C_O --trace=AM_PROG_FC_C_O
--trace=LT_CONFIG_LTDL_DIR --trace=LT_INIT --trace=LT_SUPPORTED_TAG
--trace=_AM_SUBST_NOTMAKE --trace
 =_LT_AC_TAGCONFIG --trace=_m4_warn --trace=include --trace=m4_include --trace=m4_pattern_allow
--trace=m4_pattern_forbid --trace=m4_sinclude --trace=sinclude
--reload-state=/usr/share/autoconf/autoconf/autoconf.m4f aclocal.m4 configure.in
 <at> %: <at> ! /bin/sh
m4: macro.c:1324: make_argv_ref_token: Assertion `!chain->next && chain->type == CHAIN_ARGV &&
!chain->u.u_a.skip_last' failed.
Aborted

git bisect is pointing fingers at
10801988a863c045aa0dc06b56575f1cc52bc586 [Stage 17: pass argv through
quoted strings.]

Andreas.

--

-- 
(Continue reading)

Eric Blake | 6 Mar 23:10 2008
Picon

Re: make_argv_ref_token: Assertion `!chain->next && chain->type == CHAIN_ARGV && !chain->u.u_a.skip_last' failed.

Andreas Schwab <schwab <at> suse.de> writes:

> 
> m4 1.4.10b fails on the attached input when called via autoconf.

Thanks for the report.  I'm still investigating, but I'm betting it has 
something to do with this (somewhat ugly) chunk of code, or a later use of 
phpshift:

dnl autoconf undefines the builtin "shift" :-(
dnl If possible, we use the builtin shift anyway, otherwise we use
dnl the ubercool definition I have tested so far with FreeBSD/GNU m4
ifdef([builtin],[builtin(define, phpshift, [builtin(shift, $ <at> )])],[
define([phpshift],[ifelse(index([$ <at> ],[,]),-1,,[substr([$ <at> ],incr(index([$ <at> ],
[,])))])])
])
dnl

[Why didn't they just use:

m4_define([phpshift], m4_defn([m4_shift]))

instead? It achieves the same goal, but more efficiently and with less quoting 
errors]

Once I confirm my suspicions, I will add a test case so we don't regress in the 
future.

--

-- 
Eric Blake
(Continue reading)

Eric Blake | 6 Mar 23:54 2008
Picon

Re: make_argv_ref_token: Assertion `!chain->next && chain->type == CHAIN_ARGV && !chain->u.u_a.skip_last' failed.

Eric Blake <ebb9 <at> byu.net> writes:

> 
> Once I confirm my suspicions, I will add a test case so we don't regress in 
the 
> future.
> 

$ m4
changequote([,])dnl
define(s,[builtin([shift],$ <at> )])dnl
define([i],[ifelse([$2],,[-],[$1$2: $0($1,s(s($ <at> )))])])dnl
i(1)
-
i(1,2)
12: -
i(1,2,3)
12: 13: -
i(1,2,3,4)
assertion "!chain->next && chain->type == CHAIN_ARGV && !chain-u.u_a.skip_last" 
failed: file "../../src/macro.c", line 1324
12: 13: Aborted (core dumped)

Progress!  I now have a (much smaller) example to work with, and which is 
independent of autoconf.  The patch shouldn't be too much longer, now that I 
know what caused the problem.

--

-- 
Eric Blake
(Continue reading)

Eric Blake | 7 Mar 02:30 2008
Picon

Re: make_argv_ref_token: Assertion `!chain->next && chain->type == CHAIN_ARGV && !chain->u.u_a.skip_last' failed.


According to Eric Blake on 3/6/2008 3:54 PM:
| Progress!  I now have a (much smaller) example to work with, and which is
| independent of autoconf.  The patch shouldn't be too much longer, now
that I
| know what caused the problem.

I've installed this:

http://git.sv.gnu.org/gitweb/?p=m4.git;a=commitdiff;h=ff87075

Thanks again for the report.

--
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9 <at> byu.net
Suneeth Kumar Akkera | 15 Mar 12:38 2008
Picon

"configure" script seems to be wrong, if i am not wrong!!

Hi ,
 
  Look at the following Lines:
 
idev-lx04: /home/sakkera/m4-1.4.9 39> ./configure
./configure: Command not found.

idev-lx04: /home/sakkera/m4-1.4.9 40>sh configure
: command not found
'onfigure: line 25: syntax error near unexpected token `in
'onfigure: line 25: `  case `(set -o) 2>/dev/null` in
 
Please let me know what to do...
 
 


Thanks & Regards ,

Suneeth Kumar Akkera

Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
_______________________________________________
Bug-m4 mailing list
Bug-m4 <at> gnu.org
http://lists.gnu.org/mailman/listinfo/bug-m4
Eric Blake | 15 Mar 18:14 2008
Picon

Re: "configure" script seems to be wrong, if i am not wrong!!


According to Suneeth Kumar Akkera on 3/15/2008 5:38 AM:
| *idev-lx04: /home/sakkera/m4-1.4.9 40>sh configure
| *: command not found
| 'onfigure: line 25: syntax error near unexpected token `in

What platform is this on?  It looks like you unpacked the tarball
incorrectly; is this perhaps a Windows-based machine where you mistakenly
have CRLF line endings, but are using a shell that expects only LF line
endings?  Also, 1.4.9 is not the latest version; you might want to try the
stable 1.4.10 or beta 1.4.10b.

--
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9 <at> byu.net
Ray Holme | 20 Mar 21:49 2008
Picon

format as a keyword

I don't really think this is a bug, but using the word format in an input to m4 script wreaks havoc. I got used to dealing with "index" and "substr" doing this before and was able to capttalize the usage before to get around m4 recognizing the word and trying to touch it. Format is a new word for m4 in gnu and I am sure it is a nice feature, but I use m4 to build java code, db code, ... Yes I am an m4 addict.

What I would like to do is STOP m4 from recognizing these 3 words as internal macros. They get in the way of programs and SQL and ...

I am going to try "undefine" but I doubt it will work for internal macros.

Any suggestions? (other than not using m4 for some things)

Ray Holme

Looking for last minute shopping deals? Find them fast with Yahoo! Search.
_______________________________________________
Bug-m4 mailing list
Bug-m4 <at> gnu.org
http://lists.gnu.org/mailman/listinfo/bug-m4
Eric Blake | 21 Mar 01:22 2008
Picon

Re: format as a keyword

According to Ray Holme on 3/20/2008 2:49 PM:
| I don't really think this is a bug, but using the word format in an
| input to m4 script wreaks havoc.

Which version of m4?  I ask, because prior to m4 1.4.5, format was always
treated as a builtin, but I patched it in 1.4.5 to only be recognized with
arguments.  The latest stable version is 1.4.10 (but needs a patch to run
on BSD-based stdio libraries), or you could try beta 1.4.10b (please do -
it's much faster, and I'd like some confidence that it works for everyone
before marking it as stable).

But you are indeed correct that format is a GNU extension not mentioned by 
POSIX and not present in Solaris nor BSD implementations of m4.

|
| What I would like to do is STOP m4 from recognizing these 3 words as
| internal macros. They get in the way of programs and SQL and ...
|
| I am going to try "undefine" but I doubt it will work for internal macros.

Why do you doubt?  undefine(`format') works just fine.  It's even
documented in the manual, with an example of undefining the builtin undefine:
http://www.gnu.org/software/m4/manual/m4.html#Undefine
http://www.gnu.org/software/m4/manual/m4.html#Defn

Or disable it at the command line:
m4 -Uformat

Or, you could disable GNU extensions altogether:
m4 -G

--

-- 
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9 <at> byu.net
Gary V. Vaughan | 21 Mar 03:45 2008
Picon

Re: format as a keyword


On 20 Mar 2008, at 20:22, Eric Blake wrote:
> | What I would like to do is STOP m4 from recognizing these 3 words as
> | internal macros. They get in the way of programs and SQL and ...
> |
> | I am going to try "undefine" but I doubt it will work for internal  
> macros.
>
> Why do you doubt?  undefine(`format') works just fine.  It's even
> documented in the manual, with an example of undefining the builtin  
> undefine:
> http://www.gnu.org/software/m4/manual/m4.html#Undefine
> http://www.gnu.org/software/m4/manual/m4.html#Defn
>
> Or disable it at the command line:
> m4 -Uformat
>
> Or, you could disable GNU extensions altogether:
> m4 -G

Or you could use the -P option to rename all builtins to start with  
m4_, which
would allow you to access the substr and index macros as m4_substr and  
m4_index respectively.

Or you could manually rename just the macros you want to rename using:

define(`myprefix_substr', defn(`substr'))undefine(`substr')dnl

Cheers,
	Gary
--

-- 
   ())_.              Email me: gary <at> gnu.org
   ( '/           Read my blog: http://blog.azazil.net
   / )=         ...and my book: http://sources.redhat.com/autobook
`(_~)_

_______________________________________________
Bug-m4 mailing list
Bug-m4 <at> gnu.org
http://lists.gnu.org/mailman/listinfo/bug-m4
Ralf Wildenhues | 24 Mar 00:44 2008
Picon
Picon

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/local.at:370: m4_divert_push: KILL
../../autoconf-2.59/tests/local.at:370: m4_divert_push: BODY
../../autoconf-2.59/tests/local.at:370: m4_divert_push: KILL
../../autoconf-2.59/tests/local.at:370: the top level

Other example failures include rebuilds triggered inside the GCC tree.
This is what I used:
m4 (GNU M4) 1.4.10b.14-ca0a

I'm pretty sure this problem is rather recent.

Cheers,
Ralf

Gmane