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@xxxxxxxxxx> 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@xxxxxxxxxx
> <https://www.redhat.com>
>
