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