Hello,
I may have found a weird one with EGREP_TRADITIONAL.
It'll be hard to have a snippet though, but I'll try to explain.
The apr program has shown a weird behavior during configure execution:
configure:26378: checking whether int64_t and long use fmt %ld
configure:26413: gcc -c -g -O2 -Werror -DLINUX -D_REENTRANT -D_GNU_SOURCE
conftest.c >&5
conftest.c:161:15: error: two or more data types in declaration specifiers
161 | #define gid_t int
| ^~~
conftest.c:160:15: error: two or more data types in declaration specifiers
160 | #define uid_t int
| ^~~
conftest.c:162:17: error: two or more data types in declaration specifiers
162 | #define ssize_t int
| ^~~
configure:26413: $? = 1
The gid_t/uid_t are only defined if not found in system headers. They are
obviously available as they are standard nowadays.
I found that the problem was actually that "$EGREP_TRADITIONAL" was
undefined during the execution of AC_TYPE_UID_T.
While the corresponding symbol was constructed within a case/esac earlier
in configure, it isn't made available for the outer context, which leads to
the false negative.
I tried to add a "AC_PROG_EGREP" at the beginning of the conigure.in, but
that doesn't change anything, since _AC_PROG_EGREP_TRADITIONAL isn't
required by it.
The patch below solves the problem (without changes in apr), but that looks
a bit dirty ad AC_PROG_EGREP doesn't directly need
_AC_PROG_EGREP_TRADITIONAL:
diff --git a/lib/autoconf/programs.m4 b/lib/autoconf/programs.m4
index 618f3172..5e206b13 100644
--- a/lib/autoconf/programs.m4
+++ b/lib/autoconf/programs.m4
@@ -363,6 +363,7 @@ AC_DEFUN([AC_PROG_AWK],
# -------------
AC_DEFUN([AC_PROG_EGREP],
[AC_REQUIRE([AC_PROG_GREP])dnl
+AC_REQUIRE([_AC_PROG_EGREP_TRADITIONAL])dnl
AC_CACHE_CHECK([for egrep], ac_cv_path_EGREP,
[if echo a | $GREP -E '(a|b)' >/dev/null 2>&1
then ac_cv_path_EGREP="$GREP -E"
On Thu, Nov 17, 2022 at 7:16 PM Paul Eggert <eggert@xxxxxxxxxxx> wrote:
> On 2022-11-17 04:41, Frederic Berat wrote:
> > They have the following code in their aclocal.m4{,.cross} files:
>
> Does the attached, self-contained configure.ac illustrate the problem
> for you? I don't want to have to figure out all of Wine.
>
> Also, can you narrow down which Autoconf commit causes Wine's buggy
> configure.ac to stop working? Is it the attached one?
