[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: recursion limit of 1024 exceeded
From: |
Bruno Haible |
Subject: |
Re: recursion limit of 1024 exceeded |
Date: |
Sat, 12 Dec 2020 17:25:33 +0100 |
User-agent: |
KMail/5.1.3 (Linux/4.4.0-193-generic; KDE/5.18.0; x86_64; ; ) |
Dagobert Michelsen wrote:
> autoconf (GNU Autoconf) 2.69
> automake (GNU automake) 1.16.1
Even with these (not exactly the newest) versions of autoconf and
automake, the gnulib-tool create-testdir command succeeds for me.
> meanwhile I tried to update autoconf to 2.70 with
> 3 unexpected failures and automake to 14 unexpected failures which I will
> report on the respective mailing lists.
Yes, please!
> >> gm4:configure.ac:4574: recursion limit of 1024 exceeded, use -L<N> to
> >> change it
The maximum recursion limit of m4 depends how it was built. Mine has
$ m4 --help|grep limit
-L, --nesting-limit=NUMBER change nesting limit, 0 for unlimited [0]
Yours surely has
$ m4 --help|grep limit
-L, --nesting-limit=NUMBER change nesting limit, 0 for unlimited [1024]
The default value for -L comes from this code:
if (c_stack_action (fault_handler) == 0)
nesting_limit = 0;
This means, if m4 can react on stack overflow without knowing a priori how many
recursive macro invocations it can handle — this is the case when libsigsegv is
installed or the simple heuristic in c-stack.c works —, it does so. Only in the
other case, it uses the fixed-size nesting limit.
What I don't understand, is:
- why on your system the c-stack.c heuristic, specifically tailored for
Solaris, did not work,
- why, when (on a glibc system) I use a limit even as low as -L 1,
'aclocal -I glm4' and 'autoconf' run fine in the generated testdir.
> > m4 --version
> m4 (GNU M4) 1.4.18
By the way, autom4te does not look up m4 in $PATH; it uses the M4 environment
variable or a program in a fixed location. Look into autom4te to find out which
m4 it actually uses.
Bruno