[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Possible regressions with trunk autoconf (vs 2.71)

From: Frederic Berat
Subject: Possible regressions with trunk autoconf (vs 2.71)
Date: Wed, 16 Nov 2022 08:41:47 +0100


In the past few months, I worked on a tool that massively rebuild packages
that depend on a specific other package, in order to help spot problems as
early as possible (on Fedora and RHEL so far).

I used this tool to check whether a new version of autoconf could lead to
build failures in other packages, as 2.70 did.
The result of this showed that, out of about 1165 packages in Fedora, there
were around 70 new failures with autoconf 2.72c, and about 85 with trunk
(commit 3cc9b414 at that time). Most of these failures are due to an
invalid syntax in the generated configure script (generally regenerated
through autoreconf).

Earlier this week, I started to bisect when the failures started to appear,
starting from 2.72c, and found the following commit:

* b27bc3e2 2021-08-31 Paul Eggert  | Port AC_LANG_CALL(C) to C++

Based on what the commit does, this doesn't make much sense to me. Either I
miss something, or this commit only exposes another problem, which I
haven't figured out yet. Since most of the packages are still using
"obsolete" macros, it's hard to completely exclude that the syntax error is
not due to incorrect syntax in the AC file.

For now, the only thing I could do this week, is to massively rebuild the
1165 packages with a revert of this patch to verify that the assumption was
correct. And so far: meh. Although that seems to work based on 2.72c
(builds are still running), there are still about 10 failures for which
there is a syntax error in configure with trunk.

For reference, a candidate for the investigation based on 2.72c is libpng,
a candidate for investigation based on trunk is krb5 (assuming there are 2
distinct problems).

My next step is to compare the configure script, with and without the
revert for autoconf 2.72c and libpng first, then try to figure out with
which commit I could do the same for krb5 if needed.

Any help or advice to investigate further are welcome.

Frédéric Bérat

Senior Software Engineer, Platform Tools

Red Hat <>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]