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
