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

Previous Next

To reply to this bug, email your comments to 49901 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Денис Эпиков <danwerspb <at> gmail.com>
To: bug-automake <at> gnu.org
Subject: Bug in build c-ares
Date: Thu, 5 Aug 2021 22:44:46 +0300

[Message part 1 (text/plain, inline)]

Hi!
I have a bug.
Build environment - Debian testing latest

root <at> debian10-work:~# apt source -b c-ares
Reading package lists... Done
NOTICE: 'c-ares' packaging is maintained in the 'Git' version control
system at:
https://salsa.debian.org/debian/c-ares.git
Please use:
git clone https://salsa.debian.org/debian/c-ares.git
to retrieve the latest (possibly unreleased) updates to the package.
Skipping already downloaded file 'c-ares_1.17.1-1.dsc'
Skipping already downloaded file 'c-ares_1.17.1.orig.tar.gz'
Skipping already downloaded file 'c-ares_1.17.1.orig.tar.gz.asc'
Skipping already downloaded file 'c-ares_1.17.1-1.debian.tar.xz'
Need to get 0 B of source archives.
Skipping unpack of already unpacked source in c-ares-1.17.1
dpkg-buildpackage: info: source package c-ares
dpkg-buildpackage: info: source version 1.17.1-1
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Gregor Jasny <
gjasny <at> googlemail.com>
dpkg-buildpackage: info: host architecture amd64
 dpkg-source --before-build .
 debian/rules clean
dh clean
   dh_autoreconf_clean
   dh_clean
 debian/rules build
dh build
   dh_update_autotools_config
   dh_autoreconf
aclocal: installing 'm4/ax_ac_append_to_file.m4' from
'/usr/share/aclocal/ax_ac_append_to_file.m4'
aclocal: installing 'm4/ax_ac_print_to_file.m4' from
'/usr/share/aclocal/ax_ac_print_to_file.m4'
aclocal: installing 'm4/ax_add_am_macro_static.m4' from
'/usr/share/aclocal/ax_add_am_macro_static.m4'
aclocal: installing 'm4/ax_am_macros_static.m4' from
'/usr/share/aclocal/ax_am_macros_static.m4'
aclocal: installing 'm4/ax_check_gnu_make.m4' from
'/usr/share/aclocal/ax_check_gnu_make.m4'
aclocal: installing 'm4/ax_code_coverage.m4' from
'/usr/share/aclocal/ax_code_coverage.m4'
aclocal: installing 'm4/ax_cxx_compile_stdcxx.m4' from
'/usr/share/aclocal/ax_cxx_compile_stdcxx.m4'
aclocal: installing 'm4/ax_cxx_compile_stdcxx_11.m4' from
'/usr/share/aclocal/ax_cxx_compile_stdcxx_11.m4'
aclocal: installing 'm4/ax_file_escapes.m4' from
'/usr/share/aclocal/ax_file_escapes.m4'
aclocal: installing 'm4/ax_require_defined.m4' from
'/usr/share/aclocal/ax_require_defined.m4'
aclocal: error: too many loops
aclocal: Please contact <bug-automake <at> gnu.org>.
 at /usr/share/automake-1.16/Automake/Channels.pm line 655.
Automake::Channels::msg("automake", "", "too many loops") called at
/usr/share/automake-1.16/Automake/ChannelDefs.pm line 226
Automake::ChannelDefs::prog_error("too many loops") called at
/usr/bin/aclocal line 1187
autoreconf: aclocal failed with exit status: 255
dh_autoreconf: error: autoreconf -f -i returned exit code 1
make: *** [debian/rules:6: build] Error 255
dpkg-buildpackage: error: debian/rules build subprocess returned exit
status 2
E: Build command 'cd c-ares-1.17.1 && dpkg-buildpackage -b -uc' failed.
root <at> debian10-work:~#

DP

[Message part 2 (text/html, inline)]

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

From: Karl Berry <karl <at> freefriends.org>
To: danwerspb <at> gmail.com
Cc: 49901 <at> debbugs.gnu.org
Subject: Re: bug#49901: Bug in build c-ares
Date: Thu, 5 Aug 2021 15:41:43 -0600

    aclocal: error: too many loops

1) Thanks for the report.
2) Agreed there is a bug somewhere.
3) I know you provided a recipe for reproducing (thank you),
But I just can't debug with your development configure.ac from
scratch, especially since I'm not on Debian.

Thus it would help greatly if you could narrow it down by commenting out
macros until you see where the problem lies, and then create a
standalone source tree (i.e., not involving running apt or git) and post
that.

Else, all I can do is put this in the "to be looked at by someone else"
pile (https://debbugs.gnu.org/cgi/pkgreport.cgi?package=automake#_0_4_3).
Sorry, I wish I could do better, but that's the reality. --best, karl.

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

From: Karl Berry <karl <at> freefriends.org>
To: 49901 <at> debbugs.gnu.org
Subject: Re: bug#49901: Bug in build c-ares [too many loops]
Date: Fri, 6 Aug 2021 19:00:20 -0600

I searched for "too many loops" in the bug-automake list archive.
It has been previously reported several times. Seems to be related to
autoconf-archive, especially the AX_CXX_COMPILE_STDCXX_14 macro
(or related, presumably).

In https://bugs.gnu.org/47848, I found a suggestion in the code that
rerunning aclocal may be necessary if files are installed.

https://bugs.gnu.org/25250 reports that rerunning aclocal sufficed.

https://bugs.gnu.org/24807 and especially https://bugs.gnu.org/23639
have an idea for the actual culprit:
    ... first run of autoreconf fails when I use
    AX_CXX_COMPILE_STDCXX_14 macro from autoconf-archive (version
    2016.03.20-r1 installed via portage on Gentoo), and only when I use
    it.  Second run immediately after it just works.

In https://lists.gnu.org/archive/html/bug-automake/2010-01/msg00006.html
Ralf writes, in response to the problem going away with a new release:
    This typically shows up when the macro file aclocal finds have some
    inconsistency, or aclocal finds macros from a different Libtool version
    that those which libtoolize installs into your package, or you have old
    macro files lying around in your package somewhere, possibly
    concatenated in some old aclocal.m4 or acinclude.m4 file.
(So, quite plausible that autoconf-archive is involved.)

So far as I saw (maybe I missed it), none of these reports, other than
yours, include an actual failing case that can be rerun.

With this info, can you cut down your c-ares project to a small test
that tries to exercise AX_CXX_COMPILE_STDCXX_14 or whatever you are
using? That would make it a lot more plausible to debug.

Anyway, adding this info for the record in case someone has the time and
energy to look further (which would be fantastic). --thanks, karl.

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

From: Brad House <brad <at> brad-house.com>
To: 49901 <at> debbugs.gnu.org
Subject: Re: bug#49901: Bug in build c-ares [too many loops]
Date: Tue, 17 Aug 2021 11:17:47 -0400

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.  At first glance it appears to be an issue introduced 
between automake 1.16.1 and 1.16.3.

I actually did some testing on MacOS 11.4 with automake 1.16.4 and can 
reproduce the issue.  Whereas 1.16.1 on CentOS 8 it works fine. I 
haven't tried backing off automake to 1.16.1 on MacOS.

Reported issues for c-ares are here:

https://github.com/c-ares/c-ares/issues/409
https://github.com/c-ares/c-ares/issues/416

Rerunning autoreconf -fi appears to succeed, but then when building 
after configure, make immediately throws an error so it clearly didn't 
actually work.

The autotools build hasn't been touched in years short of a code 
reorganization a year or so ago.

I haven't had time yet to investigate if there is an older version of 
c-ares that works with the newer automake to try to figure out a trigger.

I know this isn't much information to go off of, but the user just told 
me they had opened this issue so I wanted to chime in as I'm not sure 
when I'll have a chance to investigate further.

-Brad

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

From: Денис Эпиков <danwerspb <at> gmail.com>
To: 49901 <at> debbugs.gnu.org
Subject: Re: bug#49901: Bug in build c-ares
Date: Tue, 17 Aug 2021 19:19:22 +0300

[Message part 1 (text/plain, inline)]

Sorry, I am not qualified to troubleshoot this problem

пт, 6 авг. 2021 г. в 00:41, Karl Berry <karl <at> freefriends.org>:

>     aclocal: error: too many loops
>
> 1) Thanks for the report.
> 2) Agreed there is a bug somewhere.
> 3) I know you provided a recipe for reproducing (thank you),
> But I just can't debug with your development configure.ac from
> scratch, especially since I'm not on Debian.
>
> Thus it would help greatly if you could narrow it down by commenting out
> macros until you see where the problem lies, and then create a
> standalone source tree (i.e., not involving running apt or git) and post
> that.
>
> Else, all I can do is put this in the "to be looked at by someone else"
> pile (https://debbugs.gnu.org/cgi/pkgreport.cgi?package=automake#_0_4_3).
> Sorry, I wish I could do better, but that's the reality. --best, karl.
>

[Message part 2 (text/html, inline)]

Message #20 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 13:06:16 -0400

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.  I suggest simply not
doing that, and aclocal will probably work as expected.  Just delete
this file and delete the XC_OVR_ZZ60 line from configure.ac and I
expect your aclocal failure will go away.

The likely reason why the issue is intermittent is because aclocal
will not see this definition on its first pass of a clean workspace,
and the "too many loops" error happens because the state changes in
the middle of the aclocal run, once the redefinition is incorporated
into aclocal.m4 (and things might even appear to work again after
that point, until you delete aclocal.m4 and go again).

If you really need something like this to support bootstrapping with
Autoconf 2.57 (which is getting close to 20 years old now!), I suggest
you find another solution that doesn't involve redefining the internals
on newer Autoconf versions.

Cheers,
  Nick

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

From: Brad House <brad <at> brad-house.com>
To: 49901 <at> debbugs.gnu.org
Subject: Re: bug#49901: Bug in build c-ares [too many loops]
Date: Tue, 17 Aug 2021 13:20:39 -0400

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.  I suggest simply not
> doing that, and aclocal will probably work as expected.  Just delete
> this file and delete the XC_OVR_ZZ60 line from configure.ac and I
> expect your aclocal failure will go away.
<snip>
> If you really need something like this to support bootstrapping with
> Autoconf 2.57 (which is getting close to 20 years old now!), I suggest
> you find another solution that doesn't involve redefining the internals
> on newer Autoconf versions.
>

Thanks for taking a glance at this, unfortunately it didn't correct the 
issue:

bhouse:c-ares-master bhouse$ autoreconf -fiv
autoreconf: export WARNINGS=
autoreconf: Entering directory '.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4 --install
aclocal: installing 'm4/ax_ac_append_to_file.m4' from 
'/usr/local/share/aclocal/ax_ac_append_to_file.m4'
aclocal: installing 'm4/ax_ac_print_to_file.m4' from 
'/usr/local/share/aclocal/ax_ac_print_to_file.m4'
aclocal: installing 'm4/ax_add_am_macro_static.m4' from 
'/usr/local/share/aclocal/ax_add_am_macro_static.m4'
aclocal: installing 'm4/ax_am_macros_static.m4' from 
'/usr/local/share/aclocal/ax_am_macros_static.m4'
aclocal: installing 'm4/ax_check_gnu_make.m4' from 
'/usr/local/share/aclocal/ax_check_gnu_make.m4'
aclocal: overwriting 'm4/ax_code_coverage.m4' with 
'/usr/local/share/aclocal/ax_code_coverage.m4'
aclocal: installing 'm4/ax_cxx_compile_stdcxx.m4' from 
'/usr/local/share/aclocal/ax_cxx_compile_stdcxx.m4'
aclocal: overwriting 'm4/ax_cxx_compile_stdcxx_11.m4' with 
'/usr/local/share/aclocal/ax_cxx_compile_stdcxx_11.m4'
aclocal: installing 'm4/ax_file_escapes.m4' from 
'/usr/local/share/aclocal/ax_file_escapes.m4'
aclocal: installing 'm4/libtool.m4' from 
'/usr/local/share/aclocal/libtool.m4'
aclocal: installing 'm4/ltoptions.m4' from 
'/usr/local/share/aclocal/ltoptions.m4'
aclocal: installing 'm4/ltsugar.m4' from 
'/usr/local/share/aclocal/ltsugar.m4'
aclocal: installing 'm4/ltversion.m4' from 
'/usr/local/share/aclocal/ltversion.m4'
aclocal: installing 'm4/lt~obsolete.m4' from 
'/usr/local/share/aclocal/lt~obsolete.m4'
aclocal: installing 'm4/ax_require_defined.m4' from 
'/usr/local/share/aclocal/ax_require_defined.m4'
aclocal: error: too many loops
aclocal: Please contact <bug-automake <at> gnu.org>.
 at 
/usr/local/Cellar/automake/1.16.4/share/automake-1.16/Automake/Channels.pm 
line 655.
    Automake::Channels::msg("automake", "", "too many loops") called at 
/usr/local/Cellar/automake/1.16.4/share/automake-1.16/Automake/ChannelDefs.pm 
line 226
    Automake::ChannelDefs::prog_error("too many loops") called at 
/usr/local/bin/aclocal line 1187
autoreconf: error: aclocal failed with exit status: 255

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

From: Brad House <brad <at> brad-house.com>
To: 49901 <at> debbugs.gnu.org
Subject: Re: bug#49901: Bug in build c-ares [too many loops]
Date: Tue, 17 Aug 2021 16:51:39 -0400

This ended up being the fix to needing to run autoreconf -fi multiple times:
https://github.com/c-ares/c-ares/commit/e73fb47

Which appears to not be specific to c-ares as we got the logic from:
https://github.com/fenrus75/powertop/pull/82
https://bugzilla.redhat.com/show_bug.cgi?id=1835638

After that, there is also the issue that the newer ax_code_coverage.m4 
that is automatically pulled in is not API compatible as it removes 
@CODE_COVERAGE_RULES@ which isn't too friendly, plus adds a slew of 
additional .m4 dependencies that had to be imported.

And then finally, there is actually a bug in the latest 
ax_code_coverage.m4 that quotes AC_MSG_ERROR() which causes older 
autoconf/automake versions to barf.
https://github.com/c-ares/c-ares/commit/3883d99b05a845e4b40fc25c43ca83db70f4f20f#diff-fe38622a6c742be1bb93e6e65a0728f659114b3dc8d88172cb8844fa963418f9

I'm not sure where to report the last 2 issues.

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

Message #32 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 17:13:13 -0400

On 17/08/2021, Brad House via Bug reports for Automake
<bug-automake <at> gnu.org> wrote:
> This ended up being the fix to needing to run autoreconf -fi multiple
> times:
> https://github.com/c-ares/c-ares/commit/e73fb47

Probably an OK workaround.  I suspect the effect of this change is to get
aclocal to pull in the ax_require_defined.m4 file on the first pass which
avoids the "too many loops" problem but not the include order problem
(which may not actually matter).

> After that, there is also the issue that the newer ax_code_coverage.m4
> that is automatically pulled in is not API compatible as it removes
> @CODE_COVERAGE_RULES@ which isn't too friendly, plus adds a slew of
> additional .m4 dependencies that had to be imported.

You can avoid things being automatically imported by not enabling
aclocal --install mode by default (remove this setting from
ACLOCAL_AMFLAGS in your Makefile.am files).  The default behaviour
is to use the files distributed with your package in preference to
newer versions that happen to be installed on user's systems.

I expect this also would avoid the "too many loops" problem.

> And then finally, there is actually a bug in the latest
> ax_code_coverage.m4 that quotes AC_MSG_ERROR() which causes older
> autoconf/automake versions to barf.
> https://github.com/c-ares/c-ares/commit/3883d99b05a845e4b40fc25c43ca83db70f4f20f#diff-fe38622a6c742be1bb93e6e65a0728f659114b3dc8d88172cb8844fa963418f9

The original quotation looks reasonable, so this change seems
questionable to me.  Probably there are real quotation bugs
somewhere else.

> I'm not sure where to report the last 2 issues.

For issues with the autoconf-archive macros, they have their own mailing
lists:

  https://savannah.gnu.org/mail/?group=autoconf-archive

Cheers,
  Nick

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

From: Thomas Jahns <jahns <at> dkrz.de>
To: bug-automake <at> gnu.org
Subject: Re: bug#49901: Bug in build c-ares [too many loops]
Date: Wed, 1 Sep 2021 16:33:22 +0200

[Message part 1 (text/plain, inline)]

On 8/17/21 7:06 PM, Nick Bowler wrote:
> If you really need something like this to support bootstrapping with
> Autoconf 2.57 (which is getting close to 20 years old now!), I suggest
> you find another solution that doesn't involve redefining the internals
> on newer Autoconf versions.

I found that to support older autoconf versions, it was useful to put 
overrides into conditional blocks like this:

m4_if(m4_version_compare(m4_PACKAGE_VERSION,[2.70]),[-1],
  [m4_include([m4/ac_fc_module_output_flag.m4])])

Regards, Thomas
-- 
Thomas Jahns
HPC-Gruppe
Abteilung Anwendungssoftware

Deutsches Klimarechenzentrum GmbH
Bundesstraße 45a • D-20146 Hamburg • Germany

Phone:  +49 40 460094-151
Fax:    +49 40 460094-270
Email:  Thomas Jahns <jahns <at> dkrz.de>
URL:    www.dkrz.de

Geschäftsführer: Prof. Dr. Thomas Ludwig
Sitz der Gesellschaft: Hamburg
Amtsgericht Hamburg HRB 39784

[smime.p7s (application/pkcs7-signature, attachment)]

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

From: Karl Berry <karl <at> freefriends.org>
To: 49901 <at> debbugs.gnu.org
Subject: bug#49901: Bug in build c-ares
Date: Sun, 19 Sep 2021 15:08:57 -0600

It would be good to find a way to improve aclocal in the way that Nick
suggests. Marking this bug as "needs help" ... -k

Previous Next

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