GNU bug report logs - #77851
AM_RUN_LOG not found due to ustar by default

Previous Next

To reply to this bug, email your comments to 77851 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: Karl Berry <karl <at> freefriends.org>
To: Ross.Burton <at> arm.com
Cc: bug-automake <at> gnu.org
Subject: AM_RUN_LOG not found due to ustar by default
Date: Wed, 16 Apr 2025 14:56:34 -0600

Hi Ross - continuing on bug-automake from your report at
https://lists.gnu.org/archive/html/automake/2025-04/msg00002.html.
(No reason to bother platform-testers with this.)

    > I repeated my tests and rebuilds of existing source trees that have
    > been configured with 1.70 still break for me:

As expected, since I didn't make any changes to fix it, since we could
never reproduce your breakage.

    Reverting 2d2ff6070ca13428032c14f1d1cfd57b6b22e42d (use ustar by
    default) makes this go away.

Yes, also as expected. But we have to find out why.

    1. build intltool out-of-tree from a fresh tarball with automake 1.17.0

Where did you get this intltool, precisely? Not that it's likely to
matter, granted, but for purposes of reproducing ...

    1. build intltool out-of-tree from a fresh tarball with automake 1.17.0
    2. delete the build tree, autoreconf the same source tree with 1.17.92

Although the automake change is provoking the bug, I think a crucial
question is what version of autoconf you are using, not
automake. Because autom4te is part of autoconf, not automake, as we
previously discussed. Thus I suggest trying with the latest released
autoconf, 2.72, from
https://ftp.gnu.org/gnu/autoconf/autoconf-2.72.tar.xz.

As I recall, you were using an autoconf development version from
git. Maybe that is the culprit. Otherwise, it continues to be strange
that no one else has reported or can reproduce the problem.

As I wrote before, all I can think of is for you to make a tarball of
your source tree, including autom4te.cache, after each step. Then, if
we're starting from (supposedly) the same source, and running
(supposedly) the same versions of the autotools, we should be able to
see at what point they diverge.

Also, what happens if you build from the start with 1.17.92? (I.e., no
autoreconf involved.) Does it find AM_TRY_LOG?

Best,
Karl

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

From: Ross Burton <Ross.Burton <at> arm.com>
To: Karl Berry <karl <at> freefriends.org>
Cc: "bug-automake <at> gnu.org" <bug-automake <at> gnu.org>
Subject: Re: AM_RUN_LOG not found due to ustar by default
Date: Wed, 16 Apr 2025 21:42:39 +0000

On 16 Apr 2025, at 21:56, Karl Berry <karl <at> freefriends.org> wrote:
>    1. build intltool out-of-tree from a fresh tarball with automake 1.17.0
>
> Where did you get this intltool, precisely? Not that it's likely to
> matter, granted, but for purposes of reproducing ...

The intltool 0.51.0 tarball on launchpad[1].

> Although the automake change is provoking the bug, I think a crucial
> question is what version of autoconf you are using, not
> automake. Because autom4te is part of autoconf, not automake, as we
> previously discussed. Thus I suggest trying with the latest released
> autoconf, 2.72, from
> https://ftp.gnu.org/gnu/autoconf/autoconf-2.72.tar.xz.

We’re using autoconf 2.72e with a few patches[2] which I now see is a pre-release not a patch release.  One glorious day the world shall use the same numbering scheme…. I shall update to the final release and hope that one of the six or so commits that we’re missing is responsible!

> As I wrote before, all I can think of is for you to make a tarball of
> your source tree, including autom4te.cache, after each step. Then, if
> we're starting from (supposedly) the same source, and running
> (supposedly) the same versions of the autotools, we should be able to
> see at what point they diverge.

I have archives of each of the trees, after autoreconf. Is there a way to get more visibility into what autom4te is doing?

> Also, what happens if you build from the start with 1.17.92? (I.e., no
> autoreconf involved.) Does it find AM_TRY_LOG?

Yes, that works fine. The only failure case is when our source tree has been reconfigured with 1.17.0, which is “interesting" because intltool is already configured, being a tarball.  There’s a chance that our setup is triggering some latent bug but I’ve never seen this behaviour with autotools upgrades before…

Ross

[1] as per https://git.yoctoproject.org/poky/tree/meta/recipes-devtools/intltool/intltool_0.51.0.bb
[2] as per https://git.yoctoproject.org/poky/tree/meta/recipes-devtools/autoconf/autoconf_2.72e.bb

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

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

From: Karl Berry <karl <at> freefriends.org>
To: Ross.Burton <at> arm.com
Cc: 77851 <at> debbugs.gnu.org
Subject: Re: bug#77851: AM_RUN_LOG not found due to ustar by default
Date: Mon, 21 Apr 2025 14:42:16 -0600

Hi Ross,

    I shall update to the final [autoconf] release 

Have you had a chance to try this? I would like to get to the bottom of
this so I can make the release.

    because intltool is already configured, being a tarball.  

Your intltool link does not seem to provide any tarball.

    [1] as per
    https://git.yoctoproject.org/poky/tree/meta/recipes-devtools/intltool/intltool_0.51.0.bb

What command do I type (or button/link do I click) to get the code so I
can try to reproduce?  Git clone didn't work. I see no instructions. I
suppose it's obvious to most people, but sorry, I'm stymied.

$ git clone -q https://git.yoctoproject.org/poky/tree/meta/recipes-devtools/intltool/intltool_0.51.0.bb
fatal: repository 'https://git.yoctoproject.org/poky/tree/meta/recipes-devtools/intltool/intltool_0.51.0.bb/' not found

    I've never seen this behaviour with autotools upgrades before...

Presumably it's related to the ustar change being so "early" in
configure. AM_INIT_AUTOMAKE hasn't changed in such a way for many years.

Possibly adding
AC_REQUIRE([AM_RUN_LOG])dnl
(after the other AC_REQUIREs, as below) would work around the problem?
I didn't try since I can't reproduce. --thanks, karl.

--- a/m4/init.m4
+++ b/m4/init.m4
@@ -99,6 +99,7 @@ AC_SUBST([mkdir_p], ['$(MKDIR_P)'])
 AC_REQUIRE([AC_PROG_AWK])dnl
 AC_REQUIRE([AC_PROG_MAKE_SET])dnl
 AC_REQUIRE([AM_SET_LEADING_DOT])dnl
+AC_REQUIRE([AM_RUN_LOG])dnl
 _AM_IF_OPTION([tar-ustar], [_AM_PROG_TAR([ustar])],
   [_AM_IF_OPTION([tar-pax], [_AM_PROG_TAR([pax])],
     [_AM_IF_OPTION([tar-v7], [_AM_PROG_TAR([v7])],

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

From: Karl Berry <karl <at> freefriends.org>
To: Ross.Burton <at> arm.com
Cc: 77851 <at> debbugs.gnu.org
Subject: Re: bug#77851: AM_RUN_LOG not found due to ustar by default
Date: Sat, 3 May 2025 11:10:43 -0600

Hi Ross - I tried to again to reproduce your AC_RUN_LOG leftover after
autoreconf, following your original report at
  https://lists.gnu.org/archive/html/automake/2025-02/msg00037.html
and followups over the last couple of months.

Downloaded intltool from https://launchpad.net/intltool/+download
and unpacked:
wget https://launchpad.net/intltool/trunk/0.51.0/+download/intltool-0.51.0.tar.gz
tar xf intltool-0.51.0.tar.gz

I'm using autoconf-2.72, since the url for your patches for 
autoconf-2.72e is now "path not found":
  https://git.yoctoproject.org/poky/tree/meta/recipes-devtools/autoconf/autoconf_2.72e.bb

$ autoconf --version | sed 1q
autoconf (GNU Autoconf) 2.72

Ran automake 1.17:
$ automake-1.17 --version | sed 1q
automake (GNU automake) 1.17

$ automake-1.17

I get expected warnings about using a different version of autoconf and
automake than the intltools tarball. I presume you get them too:
  aclocal.m4:17: warning: this file was generated for autoconf 2.69.
  You have another version of autoconf.  It may work, but is not guaranteed to.
  If you have problems, you may need to regenerate the build system entirely.
  To do so, use the procedure documented by the package, typically 'autoreconf'.
  configure.ac:7: error: version mismatch.  This is Automake 1.17,
  configure.ac:7: but the definition used by this AM_INIT_AUTOMAKE
  configure.ac:7: comes from Automake 1.14.1.  You should run

Fine. Using automake-1.17.92 (*), run autoreconf (no output):
$ PATH=/tmp/am92/bin:$PATH automake --version | sed 1q
automake (GNU automake) 1.17.92
$ PATH=/tmp/am92/bin:$PATH autoreconf

Observe that AM_RUN_LOG is not in the generated configure:
$ \grep AM_RUN config*

And it is in aclocal.m4:
$ \grep AM_RUN config*
$ \grep AM_RUN *
aclocal.m4:# AM_RUN_LOG(COMMAND)
aclocal.m4:AC_DEFUN([AM_RUN_LOG],
..

./configure && make also runs fine, not surprisingly.

It would appear the problem is specific to your environment.
Perhaps to your patched autoconf, perhaps to your config.site, perhaps
to something else. If you can find a way that someone other than you
can reproduce, we can look into it further.

Otherwise, I plan to make the automake release in a few days.

Thanks,
Karl

(*) Created the automake-1.17.92 installation in the usual way:
tar xf automake-1.17.92.tar.xz 
./configure --prefix=/tmp/am92
make && make install

Previous Next

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