Re: How to pinpoint aclocal failure

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[Please keep the list in the loop]

According to Yang Tse on 7/31/2008 7:44 AM:
| 2008/7/31, Eric Blake wrote:
|
|> have you tried commenting out sections of your configure.ac, to see if one
|> section in particular seems to be the culprit?
|
| A local macros file was added to m4 subdirectory as well as
| "ACLOCAL_AMFLAGS = -I m4" to the top Makefile.am, and aclocal is
| invoked as "aclocal -I m4 $ACLOCAL_FLAGS".
|
| This new macro file defines a MACRO_A which uses the definitions of
| other 11 macros on that same file, these 11 'inner' macros are not
| called from nowhere else than from MACRO_A, and none of them use even
| a single parameter. There is a single invocation of MACRO_A in
| configure.ac
|
| If MACRO_A is commented out out from configure.ac, aclocal 'finds' the
| definitions from the new m4 file but further doesn't 'see or use' them
| as expected. But aclocal (m4) fails equally with the single invocation
| commented out. Also as expected the logged onvocation of autom4te does
| not contain any reference to MACRO_A nor those on which it depends,
| but finally m4 fails.

So you are saying that the presence of the file containing the definition
of MACRO_A, even though MACRO_A is not invoked, is the trigger for m4's
success or failure?  Can you post the file containing MACRO_A for review?

|
|> The NEWS for m4 mentions a couple of memory leaks that have been resolved
|> since 1.4.5; one in regexp/patsubst handling, and one in diversion number
|> handling.  Perhaps you are using a construct that repeatedly creates new
|> regexp and thus leaks, or which uses insanely large diversion numbers?
|
| I have never understanded very well the term 'diversion' in all the m4
| context. Do you have a link ?

http://www.gnu.org/software/autoconf/manual/html_node/Diversion-support.html#Diversion-support
http://www.gnu.org/software/m4/manual/html_node/Diversions.html#Diversions

Autoconf heavily uses diversions under the hood, but generally, autoconf
macro writers need not worry about diversions, since autoconf already does
all the work.  In other words, if you don't call any macro named
m4_divert*, this shouldn't be your problem.

|
| In any case, MACRO_A, nor any of its dependants, does not iterate nor
recurses.
|
|> requiring gm4 1.4.5 might be a losing proposition since you have already
|> confirmed that upgrading to newer software solves the problem for you.
|
| The reason for that version requirement on the Solaris platform is due
| to http://www.blastwave.org/ not having a more recent version of m4
| for Solaris.

If you are worried about supporting only pre-compiled builds of m4, but
need a newer build of m4 to get things to work, then consider contributing
a newer pre-compiled version of m4 for hosting on that site.

|
|>  [...] generally, if you have a
|> recursion bug in your configure.ac, then it would run out of memory
|> independently of m4 version.
|
| As a matter of fact I really suspect some tool problem, but its not
| clear which one has the 'real' problem that the addition of the new
| macros, even when not used, triggers it.
|
|> Yes.  Within configure.ac, you can use m4_traceon/m4_traceoff, or add
|> messages to grep for.  With autom4te, you can use the --trace command to
|> trace a particular macro; the trace output generally appears under the
|> autom4te.cache directory.
|
| Well what I really need to trace is aclocal or autom4te.
|
| What hacking would be needed in autom4te 2.61 so that it writes out a
| file with what it is going to feed to m4 before actually doing so ?

You can use the --verbose flag to aclocal to get the exact command line
that m4 is being invoked with, then rerun just that command line to prove
that the problem lies in m4 running out of memory (and not in autom4te's
wrapping of m4 execution).

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

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkiVJdoACgkQ84KuGfSFAYC0JQCfVcAlOFtWhSxUtAPm0ZYwQniq
zrQAoM+IPNWZXQ/VWvAn53Id+XeUkgff
=xJCu
-----END PGP SIGNATURE-----