[Top][All Lists]

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

Re: How to pinpoint aclocal failure

From: Eric Blake
Subject: Re: How to pinpoint aclocal failure
Date: Sat, 02 Aug 2008 21:28:26 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20080708 Thunderbird/ Mnenhy/

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, 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, 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
| If MACRO_A is commented out out from, 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 ?

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
|> 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 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, 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, 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
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at
Comment: Using GnuPG with Mozilla -


reply via email to

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