On 17/08/2021, Brad House via Bug reports for Automake <bug-automake@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@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
