Please don't top-post on this mailing list. On Tue, Mar 28, 2023, at 1:29 PM, Frederic Berat wrote: > On Tue, Mar 28, 2023 at 7:04 PM Nick Bowler <nbowler@xxxxxxxxxx> wrote: >> On 2023-03-28, Zack Weinberg <zack@xxxxxxxxxxxx> wrote: >> > Can someone who understands the problem described at >> > https://lists.gnu.org/archive/html/autoconf/2022-11/msg00129.html >> > please construct a minimal, self-contained configure.ac that >> > reproduces that problem? >> >> This should be a good approximation: ... > That's close enough, yes. You actually don't need the "else" though, it's > enough to isolate the first call to egrep: > > % cat >configure.ac <<'EOF' > AC_INIT([test], [0]) > > AC_PROG_CPP > AC_PROG_EGREP > > # uncomment to make this work on new autoconf > # m4_ifdef([_AC_PROG_EGREP_TRADITIONAL], [_AC_PROG_EGREP_TRADITIONAL]) > > if false; then > AC_EGREP_HEADER([printf], [stdio.h]) > fi > > AC_MSG_CHECKING([if stuff works]) > AC_EGREP_HEADER([malloc], [stdlib.h], > [AC_MSG_RESULT([ok])], [AC_MSG_RESULT([nope])]) OK, I understand the issue now. _AC_PROG_EGREP_TRADITIONAL is actually quite new (introduced in 0c762675, last June, post-2.71) and the idea seems to have been that AC_PROG_EGREP is quite picky -- it insists on finding an implementation that supports long lines and the -e option (not to be confused with the -E option) -- but AC_EGREP_CPP and AC_EGREP_HEADER can probably get away with using an egrep that doesn't support these things. But, AC_PROG_EGREP doesn't do the fallback check for a more limited egrep; that code is only emitted on the first actual use of AC_EGREP_HEADER, which in this case is inside the 'if false'. This configure.ac *is* incorrect, but since we are trying to make 2.73 a smooth upgrade from 2.71 I do think we should keep it working, and the obvious way to do that is to fold the "fallback check for a more limited egrep" into AC_PROG_EGREP. Any objections to that change? If not, I'll send a patch in a day or two. zw
