Re: AC_PROG_EGREP and $EGREP_TRADITIONAL and shell conditional statements

Khem Raj <[email protected]> Fri, 31 Mar 2023 23:19:27 -0700

Newsgroups	gmane.comp.sysutils.autoconf.general
Message-ID	<[email protected]>

On 3/30/23 7:24 AM, Zack Weinberg wrote:
> 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 <[email protected]> wrote:
>>> On 2023-03-28, Zack Weinberg <[email protected]> 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.
> 

I am also seeing this issue with packages using AC_EGREP_CPP
e.g. mcpp https://mcpp.sourceforge.net/download.html

when reconfigured it fails to run the resulting configure script


checking printf length modifier for the longest integer... (cached) ll
checking for value of __GNUC__... 4
checking for value of __GNUC_MINOR__... 2
../mcpp-2.7.2/configure: line 14378: syntax error near unexpected token `;;'
../mcpp-2.7.2/configure: line 14378: `    '' ;;'
NOTE: The following config.log files may provide further information.
NOTE: 
/mnt/b/yoe/master/build/tmp/work/cortexa72-yoe-linux/mcpp/2.7.2-r0/build/config.log
ERROR: configure failed

> zw
>

OpenPGP_0xBB053355919D3314.asc (application/pgp-keys, 2.5 KB)

OpenPGP_signature (application/pgp-signature, 203 B) - not displayed