PS. To elaborate further on your question from the first e-mail, The version pin is deliberate and is here to stay, sorry. However, libtool shouldn't need rebuilding for every automake release, and it will not once the fixes for the bugs that I identified make it into release(s). aclocal.m4 is *not* independent of automake and making it into a separate package would be a very bad idea conceptually, and also it would not resolve the issue. To reiterate, the version check would be completely harmless if aclocal wasn't mistakenly called because of the bug pointed in the previous e-mail.
> Should we be making aclocal its own package and have the versions > co-installable? Co-installable versions are already supported by upstream automake. Everything is versioned except bin/aclocal, bin/automake, their man pages, the info manual, share/aclocal/README and the amhello example, so Debian could in principle provide automake-1.18 and automake-1.19 side by side, with alternatives for the unversioned names. BTW, automake 1:1.18.1-4 declares "Provides: automake-1.17", which looks wrong. -- With Valediction, Kamila Szewczyk (https://iczelia.net) On 9/16/26 7:52 PM, Kamila Szewczyk wrote: > 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
