Dear Alastair, Interesting problem. This is not an automake bug. Rather, this is a problem for both libtool and autoconf maintainers (i.e., I guess still myself...). I checked your sources and squid 7.6's dist tarball was generated by automake 1.16.5. The issue with aclocal-1.18 comes from libltdl-dev as you suspected. It seems like the failure mode is a horrifying matrioshka where bugs lay at every hand that pans out a bit like this:
- autoreconf regenerates libltdl/ first, then overwrites it. debhelper 13 runs autoreconf -f -i, which enters libltdl/ and regenerates it with automake 1.19. Only then does it run libtoolize --copy --force --ltdl in the parent directory. As a result, libltdl-dev's pre-built aclocal.m4 and Makefile.in generated by automake 1.18.1 overwrite the fresh files. - libtoolize doesn't fully fix up the copied Makefile.in. It rewrites the ../m4 macro path in ACLOCAL_AMFLAGS and in aclocal.m4's m4_include lines. It does not, however, modify the dependency list in Makefile.in, which still points at $(top_srcdir)/../m4/libtool.m4. This file does not exist. - As a result, `make' regenerates aclocal.m4 on every build. Automake-generated `Makefile.in' files have an empty rule for these dependencies. A missing dependency with an empty rule always counts as out of date, and thus the inevitable rebuild runs whatever version the stock configure script names, here aclocal-1.18. Hence, you should do the following: - Debian must rebuild libtool against automake 1.19 if it hadn't done so already. That makes the missing-tool error go away, but the silent rebuild is here to stay (until item #3 on this list is fixed) and the error will return once more when automake 1.20 is released. I am unhappy about this. It makes as much sense as Pollyanna adding days to the end of the week to avoid Mondays :-). - Patch squid packaging to run autoreconf -f -i libltdl after dh_autoreconf. libltdl/ then comes out as built against automake 1.19 with correct dependencies, and the build should finish without running aclocal at all. - Inform the libtool upstream ([email protected]) that libtoolize should rewrite the macro-dir paths in the copied `Makefile.in' files. A minor related bug I spotted while digging through the source code: its filtered copy of libltdl/configure loses the execute bit (mode 0664). That's (incidentally) harmless here because the parent runs it through $SHELL instead of directly invoking it. - Inform the autoconf upstream ([email protected]) that autoreconf should run libtoolize --ltdl before recursing into subdirectories, since libtoolize is what fills them. - I am on vacation now, so I will not fix any of these bugs in +/- 3 weeks from now. If they are unfixed by the 7th of October, please e-mail me again and I will sit down to this properly. Finally: > Secondly, and probably a Debian design choice, automake ships files in > /usr/share/automake-1.19 rather than /usr/share/automake. Automake does this on purpose to allow users to have multiple versions of it installed on their operating system. This is because automake's backwards- and forwards-compatibility guarantees are (or rather were) loose. I think that every autotools project should do this, as they suffer from the same, so to say, affliction. This is explained in more detail in the automake manual if you're curious. -- With Valediction, Kamila Szewczyk (https://iczelia.net) On 9/16/26 6:31 PM, Alastair McKinstry wrote: > > On 16/09/2026 15:21, Zack Weinberg wrote: >> On Wed, Sep 16, 2026, at 5:43 AM, Alastair McKinstry wrote: >>> I maintain libtool in Debian and we were again bitten by automake hard- >>> coding aclocal version into the libtool toolchain. >> I'm not sure what you mean by this. aclocal *itself* changes only >> rarely, although it is bundled with automake (not autoconf) and shares >> automake's version number. >> >> Could you give more detail on the specific sequence of events that leads >> to breakage, please? What files are the aclocal (== automake) version >> number getting written into, and why does it break libtool when a newer >> version of aclocal than what's in those files shows up? >> >> zw > > Apologies I got some mixed up. *libtool* ships (in libltdl-dev in > Debian) the file /usr/share/libtool/aclocal.m4 that is generated by > aclocal in automake. > > Building a package (eg squid 7.6; ) which was created with libtool 2.6.2 > automake / aclocal 1.18, in an environment where automake is upgraded > to 1.19 breaks with: > > ``` > > CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/bash '/build/reproducible- > path/squid-7.6/cfgaux/missing' aclocal-1.18 -I m4 > /build/reproducible-path/squid-7.6/cfgaux/missing: line 85: > aclocal-1.18: command not found > WARNING: 'aclocal-1.18' is missing on your system. > You should only need it if you modified 'acinclude.m4' or > 'configure.ac' or m4 files included by 'configure.ac'. > make[3]: *** [Makefile:566: aclocal.m4] Error 127 > make[3]: Leaving directory '/build/reproducible-path/squid-7.6/libltdl' > > ``` > > The failure coming from aclocal.m4 in libltdl-dev. > > Secondly, and probably a Debian design choice, automake ships files in / > usr/share/automake-1.19 rather than /usr/share/automake. > > Do you know why? (Eric?) > > Its awkward as paths need to change in some other packages each automake > upgrade. > > > > Best regards > > Alastair > >
OpenPGP_0xC868F0B6DE38409D.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
