GNU bug report logs - #49901
Bug in build c-ares

Previous Next

Full log

Message #29 received at 49901 <at> debbugs.gnu.org (full text, mbox):

From: Nick Bowler <nbowler <at> draconx.ca>
To: Brad House <brad <at> brad-house.com>
Cc: 49901 <at> debbugs.gnu.org
Subject: Re: bug#49901: Bug in build c-ares [too many loops]
Date: Tue, 17 Aug 2021 16:58:19 -0400

On 17/08/2021, Brad House via Bug reports for Automake
<bug-automake <at> gnu.org> wrote:
> On 8/17/21 1:06 PM, Nick Bowler wrote:
>> On 2021-08-17, Brad House via Bug reports for Automake
>> <bug-automake <at> gnu.org> wrote:
>>> I'm one of the maintainers of the c-ares project at
>>> https://github.com/c-ares/c-ares and have had a couple of users report
>>> this issue.
>> I took a quick glance and I found this:
>>
>>    https://github.com/c-ares/c-ares/blob/main/m4/zz60-xc-ovr.m4
>>
>> which is redefining autoconf-supplied macros (AC_CONFIG_MACRO_DIR) and
>> is almost certainly the cause of your problem.
[...]
> Thanks for taking a glance at this, unfortunately it didn't correct the
> issue.

Right.  It seems aclocal is being tripped up by AX_CXX_COMPILE_STDCXX_11
and its dependencies from autoconf archive, likely by the newer versions
that are being copied in by aclocal --install.

Here is a small test case that reproduces the problem, emulating
AX_CXX_COMPILE_STDCXX_11 from Autoconf Archive v2021.02.19:

  % cat >configure.ac <<'EOF'
  AC_INIT([test], [0])
  FOO
  AC_OUTPUT
EOF

  % mkdir m4src
  % cat >m4src/00_bar.m4 <<'EOF'
  AC_DEFUN([BAR])
EOF
  % cat >m4src/10_foo.m4 <<'EOF'
  PROBLEM # This line is a problem!
  AC_DEFUN([FOO], [BAR])
EOF
  % cat >m4src/20_problem.m4 <<'EOF'
  AC_DEFUN([PROBLEM])
EOF

  % rm -f m4/*.m4
  % aclocal --system-acdir=$PWD/m4src -I m4 --install
  aclocal: installing 'm4/00_bar.m4' from '/tmp/x/m4src/00_bar.m4'
  aclocal: installing 'm4/10_foo.m4' from '/tmp/x/m4src/10_foo.m4'
  aclocal: installing 'm4/20_problem.m4' from '/tmp/x/m4src/20_problem.m4'
  aclocal: error: too many loops
  [...]

The issue is that due to how aclocal works, on the first pass it cannot
recognize that PROBLEM is a macro in 10_foo.m4 (which corresponds to
ax_cxx_compile_stdcxx_11.m4), because files are included in search
order and when 10_foo.m4 is processed, 20_problem.m4 is not included
yet.  So aclocal --install will copy only 00_bar.m4 and 10_foo.m4 into
the package.

On the second pass (after 00_bar.m4 and 10_foo.m4 are copied into
the package), the order in which these files are included has changed.
Now 20_problem.m4 is included first and this time PROBLEM is actually
recognized as a macro expansion.  So aclocal dutifully installs
20_problem.m4 into the package m4 directory.

Then aclocal bails with "too many loops" because a third pass would be
required.  If you manually run aclocal --install again, it will succeed
(since no files remain to be copied) but with the original ordering: PROBLEM
will not be recognized as a macro expansion (and the generated aclocal.m4 will
not include 20_problem.m4)

This sort of behaviour is the main reason why the aclocal documentation
suggests these files not contain anything other than macro definitions[1],
so that they are not sensitive to include order.

It is probably possible to improve aclocal to not bail out in this
scenario but autoconf-archive should still be fixed, perhaps by
moving the expansion of AX_REQUIRE_DEFINED into the expansion of
AX_CXX_COMPILE_STDCXX_11.  Or by using the Autoconf-provided
m4_pattern_forbid machinery which looks for unexpanded macros
in the ouptut to achieve a similar result.

[1] https://www.gnu.org/software/automake/manual/automake.html#Extending-aclocal

Cheers,
  Nick

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.