Re: Possible regressions with trunk autoconf (vs 2.71)

[Frederic Berat]

After a few more hours of investigation, the failure in krb5 seems to be
due to a bug in their aclocal.m4 file: a misplaced "fi" similar to the one
fixed by v2.72c-10-g68fac90c: 'AC_FUNC_ALLOCA: fix a misplaced (now fatal)
closing "fi"'.

So I guess I can only dig into the other failures one by one now.

On Wed, Nov 16, 2022 at 10:06 AM Frederic Berat <fberat@redhat.com> wrote:

> Hello again,
>
> Some progress on this, it looks like, at least for libpng, there is at one
> place where the "Port AC_LANG_CALL" seems to be the culprit.
> Specifically, the "," in the C comment, is interpreted by M4 as argument
> split which in turn leads to the syntax error.
> I made a small test where I  "overquote" the snippet, which seems to work
> around the problem for this package at least, but there may be better
> solutions:
>
> diff --git a/lib/autoconf/c.m4 b/lib/autoconf/c.m4
> index 48bd49a3..3f6e276d 100644
> --- a/lib/autoconf/c.m4
> +++ b/lib/autoconf/c.m4
> @@ -124,16 +124,16 @@ m4_define([_AC_LANG_IO_PROGRAM(C)],
>  m4_define([AC_LANG_CALL(C)],
>  [AC_LANG_PROGRAM([$1
>  m4_if([$2], [main], ,
> -[/* Override any GCC internal prototype to avoid an error.
> +[[/* Override any GCC internal prototype to avoid an error.
>     Use char because int might match the return type of a GCC
>     builtin and then its argument prototype would still apply.
>     The 'extern "C"' is for builds by C++ compilers;
>     although this is not generally supported in C code, supporting it here
> -   has little cost and some practical benefit (sr 110532).  */
> -#ifdef __cplusplus
> +   has little cost and some practical benefit (sr 110532).  */]
> +[#ifdef __cplusplus
>  extern "C"
>  #endif
> -char $2 ();])], [return $2 ();])])
> +char $2 ();]])], [return $2 ();])])
>
> The snippet of configure.ac that generated wrong code is the following:
>
> # Checks for library functions.
> AC_FUNC_STRTOD
> AC_CHECK_FUNCS([pow], , AC_CHECK_LIB(m, pow, , AC_MSG_ERROR(cannot find
> pow)) )
>
> # Some later POSIX 1003.1 functions are required for test programs,
> failure here
> # is soft (the corresponding test program is not built).
> AC_CHECK_FUNC([clock_gettime],,[AC_MSG_WARN([not building timepng])])
> AM_CONDITIONAL([HAVE_CLOCK_GETTIME], [test "$ac_cv_func_clock_gettime" =
> "yes"])
>
> AC_ARG_WITH(zlib-prefix,
>    AS_HELP_STRING([[[--with-zlib-prefix]]],
>       [prefix that may have been used in installed zlib]),
>       [ZPREFIX=${withval}],
>       [ZPREFIX='z_'])
> AC_CHECK_LIB(z, zlibVersion, ,
>     AC_CHECK_LIB(z, ${ZPREFIX}zlibVersion, , AC_MSG_ERROR(zlib not
> installed)))
>
> Specifically, this one gets wrong shell code, where the comment is split
> at the comma:
> AC_CHECK_FUNCS([pow], , AC_CHECK_LIB(m, pow, , AC_MSG_ERROR(cannot find
> pow)) )
>
> I'll now start a mass rebuild with the work around, and try to figure out
> the other errors.
>
> Fred.
>
> On Wed, Nov 16, 2022 at 8:41 AM Frederic Berat <fberat@redhat.com> wrote:
>
>> Hello,
>>
>> 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 <https://www.redhat.com>
>>
>> fberat@redhat.com
>> <https://www.redhat.com>
>>
>