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
--
Alastair McKinstry,
GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5
e: [email protected], im: @alastair:mckinstry.ie
https://mastodon.ie/@amckinstry
