Build on Debian Trixie fails due to an "incompatible" version of autoconf

[michaelklishin]

Team RabbitMQ builds recent Erlang/OTP releases on a number of Debian and Ubuntu distributions.

Recently, Erlang 26.2.x builds on Debian Trixie (yes, it is not yet GA but still) builds have started failing with

# Regenerate configure scripts using autoconf
./otp_build update_configure --no-commit
ERROR: autoconf of version 2.72 found in path! You need to have autoconf of version 2.71 in path.
make: *** [debian/rules:159: automake-stamp] Error 1
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
debuild: fatal error at line 1184:
dpkg-buildpackage -us -uc -ui -i -I failed
gbp:error: 'debuild --preserve-envvar PATH -i -I -k***' failed: it exited with 29

Unlike Debian Bookworm, Trixie ships with autoconf 2.72.x.

I cannot comment on the actual compatibility of 2.72.x but in case there are no breaking changes, this should be a matter of whitelisting 2.72.x as supported.

Trixie does not have an announced release date yet and chance are, it will ship around June 2025 or 2026.

[joaohf]

Hi,

Just adding some additional data here:

When building Erlang/OTP for Yocto (using meta-erlang layer) I've added some patches for changing autoconf version:

• https://github.com/meta-erlang/meta-erlang/blob/master/recipes-devtools/erlang/files/26/0001-Use-autoconf-2.72e.patch
• https://github.com/meta-erlang/meta-erlang/blob/master/recipes-devtools/erlang/files/27/0001-Use-autoconf-2.72e.patch
• https://github.com/meta-erlang/meta-erlang/blob/master/recipes-devtools/erlang/files/28/0001-Use-autoconf-2.72e.patch

That was necessary because each Yocto version uses a specific autoconf version (usually the latest one available). I've been testing running Erlang/OTP 26,27,28 (master branch) without any problems so far.

[rickard-green]

OTP contains all configure scripts needed already generated, so there is no need to run ./otp_build update_configure. Already generated configure scripts was introduced since different autoconf versions were incompatible which caused misconfigurations. Now we always generate all configure scripts using fixed versions (which is different in different OTP versions). We will not change that, since that prevents misconfigurations of the system.

If you modify configure.ac files, you have to re-generate configure scripts, but this is not something that we support. If you do that, I would strongly recommend not hacking the otp_build script (as in the patches above), but instead use the autoconf version that the specific OTP version needs. This in order to avoid strange misconfigurations. Downloading and building autoconf is an easy task.

[michaelklishin]

@rickard-green I'd like to bring this back to your attention. As things stand right now, Erlang 27+ cannot be built on vanilla Ubuntu 24.04 in the environments where a custom version of autoconf cannot be installed.

It is the latest LTS release of what may be the most popular Debian-based Linux distribution.

Does Erlang/OTP really need to depend on one specific autoconf version? Can both 2.71 and 2.72 be supported? That would make builds in environments such as Launchpad possible again.

Given the turtle speed at which upgrades of such software happen, without a "dual version" compatibility this major pain point for the developers of Erlang- and Elixir-based software may persist for a few years :(

[garazdawi]

I still don't understand why autoconf has to be run? If there is some patch applied to Erlang that requires running of autoconf, why can't the updated configure script also be part of that patch?

[michaelklishin]

@garazdawi it may be a package metadata problem. I will try dropping autoconf. Historically Erlang packages have had them for as long as I remember (so, since at least 2010 or so).

[garazdawi]

Autoconf used to be needed, but since Erlang/OTP 24.0.1 it is not anymore (yes, it was done in a minor patch because of issues we found in using different autoconf versions that worked in incompatible ways).

[michaelklishin]

@garazdawi thank you for clarifying that, it gives me something to work with on our side.