[Top][All Lists]

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

Re: Possible regressions with trunk autoconf (vs 2.71)

From: Nick Bowler
Subject: Re: Possible regressions with trunk autoconf (vs 2.71)
Date: Fri, 18 Nov 2022 12:45:38 -0500

On 2022-11-18, Frederic Berat <> 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, 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
> 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_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.


reply via email to

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