On 2022-11-18, Frederic Berat <fberat@xxxxxxxxxx> wrote: > The apr program has shown a weird behavior during configure execution: [...] > 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. On the apr side, the fix is probably to rewrite the problematic case statement using AS_CASE. This will allow Autoconf to "hoist" the expansion of _AC_PROG_EGREP_TRADITIONAL outside of the condition so it actually gets executed all the time. That being said ... > 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" ... something like this seems reasonable to me, especially if it solves the problem in apr, as I think it makes logical sense that AC_PROG_EGREP would do the necessary setup for AC_EGREP_CPP to work. Cheers, Nick
