Re: [sr #110215] AC_EGREP_HEADER appears to be broken in master

[Eric Blake]

On 3/24/20 3:07 PM, Nick Bowler wrote:

On 2020-03-24, Ross Burton  wrote:

As to why this is not broken with 2.69, I think I have a theory.

If I build e.g. acl with both 2.69 and master, it's notable that 2.69
has these lines in the output that do not exist in master:


checking how to run the C preprocessor... gcc  -E
checking for grep that handles long lines and -e...
/scratch/poky/hosttools/grep
checking for egrep... /scratch/poky/hosttools/grep -E
checking for ANSI C header files... yes


Probably that is it: the long-obsolete AC_HEADER_STDC, previously
used internally by AC_INCLUDES_DEFAULT, used AC_EGREP_HEADER.  The
AC_HEADER_STDC macro is now a no-op (and is not used at all within
Autoconf anymore), so that change is likely what made the first use
of AC_EGREP_HEADER the one inside the if condition, causing the
observed results.


We already have autoupdate remove a call to AC_HEADER_STDC and replace 
it with the direct side-effect results of setting STDC_HEADERS and 
TIME_WITH_SYS_TIME; should we also tweak that to preserve the 
side-effect of AC_REQUIRES([AC_EGREP_HEADER)], to minimize the pain on 
external projects unaware that they were depending on that side-effect? 
Or maybe just tweak the NEWS blurb to mention that users depending on 
$GREP being set early may need to be careful?


--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

Re: [sr #110215] AC_EGREP_HEADER appears to be broken in master

[Nick Bowler]

On 2020-03-24, Ross Burton  wrote:
> As to why this is not broken with 2.69, I think I have a theory.
>
> If I build e.g. acl with both 2.69 and master, it's notable that 2.69
> has these lines in the output that do not exist in master:
>
>> checking how to run the C preprocessor... gcc  -E
>> checking for grep that handles long lines and -e...
>> /scratch/poky/hosttools/grep
>> checking for egrep... /scratch/poky/hosttools/grep -E
>> checking for ANSI C header files... yes

Probably that is it: the long-obsolete AC_HEADER_STDC, previously
used internally by AC_INCLUDES_DEFAULT, used AC_EGREP_HEADER.  The
AC_HEADER_STDC macro is now a no-op (and is not used at all within
Autoconf anymore), so that change is likely what made the first use
of AC_EGREP_HEADER the one inside the if condition, causing the
observed results.

> Something else was causing the egrep search to happen early in the
> build.  My hunch is that the same codepath exists in apt, and now
> isn't expanding egrep earlier in the configure run.
>
> Thanks for the explanation, I'll switch out if for AS_IF and move on.

Sounds great.  And thanks for all your effort in testing and fixing all
these packages.

Cheers,
  Nick

[sr #110215] AC_EGREP_HEADER appears to be broken in master

[Ross Burton]

Follow-up Comment #1, sr #110215 (project autoconf):

This can be closed: user error.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

Re: [sr #110215] AC_EGREP_HEADER appears to be broken in master

[Ross Burton]

On Tue, 24 Mar 2020 at 17:24, Nick Bowler  wrote:
> No, this is exactly how AC_REQUIRE is supposed to be working.  The configure
> script has a bug.  Now I'm not sure why this fails for you only with latest
> autoconf, because AC_REQUIRE has worked like this for a very long time.  It
> might have worked by luck because some earlier macro previously used
> AC_PROG_EGREP, and maybe it no longer does.
>
> The result of expanding AC_REQUIRE'd macros are hoisted to the outermost
> macro expansion (although note that only macros defined with AC_DEFUN
> and friends will participate in this process).
>
> So if you have an open-coded shell "if" outside of any macro, then
> within the if body, you expand a macro that uses AC_REQUIRE, then the
> AC_REQUIRE'd macro gets expanded _within the if_.

So my understanding was that the macros get hoisted up was correct,
but the caveat that bare if needs to be AS_IF was missing.
Understood.

As to why this is not broken with 2.69, I think I have a theory.

If I build e.g. acl with both 2.69 and master, it's notable that 2.69
has these lines in the output that do not exist in master:

> checking how to run the C preprocessor... gcc  -E
> checking for grep that handles long lines and -e... 
> /scratch/poky/hosttools/grep
> checking for egrep... /scratch/poky/hosttools/grep -E
> checking for ANSI C header files... yes

Something else was causing the egrep search to happen early in the
build.  My hunch is that the same codepath exists in apt, and now
isn't expanding egrep earlier in the configure run.

Thanks for the explanation, I'll switch out if for AS_IF and move on.

Ross

Re: [sr #110215] AC_EGREP_HEADER appears to be broken in master

[Nick Bowler]

Hi Ross,

On 2020-03-24, Ross Burton  wrote:
[...]
> AC_CHECK_FUNC(statvfs,[HAVE_STATVFS=yes])
> dnl Arg, linux and bsd put their statfs function in different places
> if test x"$HAVE_STATVFS" != x"yes"; then
>AC_EGREP_HEADER(statfs,sys/vfs.h,[AC_DEFINE(HAVE_VFS_H)],[
>
> AC_EGREP_HEADER(statfs,sys/mount.h,[AC_DEFINE(HAVE_MOUNT_H)],[AC_MSG_ERROR(failed:
> Need statvfs)])
>])
> fi
> (and later looks for h_errno then fails)
>
> And the generated code does this:
>
> if test x"$HAVE_STATVFS" != x"yes"; then
> { printf "%s\n" "$as_me:${as_lineno-$LINENO}: checking for grep that
> handles long lines and
> -e" >&5
> printf %s "checking for grep that handles long lines and -e... " >&6; }
> ...
>
> So the search for egrep only happens if statvfs isn't found by
> AC_CHECK_FUNC.  My understanding is that this isn't how AC_REQUIRE
> should be working, right?

No, this is exactly how AC_REQUIRE is supposed to be working.  The configure
script has a bug.  Now I'm not sure why this fails for you only with latest
autoconf, because AC_REQUIRE has worked like this for a very long time.  It
might have worked by luck because some earlier macro previously used
AC_PROG_EGREP, and maybe it no longer does.

The result of expanding AC_REQUIRE'd macros are hoisted to the outermost
macro expansion (although note that only macros defined with AC_DEFUN
and friends will participate in this process).

So if you have an open-coded shell "if" outside of any macro, then
within the if body, you expand a macro that uses AC_REQUIRE, then the
AC_REQUIRE'd macro gets expanded _within the if_.

This is almost never the desired behaviour because autoconf will
consider the macro expanded and will not expand the dependency at other
AC_REQUIRE sites, leading to the problem you see.

There are several options for configure authors can to avoid this
problem, including:

 (1) You can use AS_IF, which will cause m4 to hoist the dependency
 expansion outside of the conditional.
 (2) You can explicitly call all dependencies such as AC_PROG_EGREP
 outside of the if.

Obviously (2) is only possible if you know the dependencies in advance
(not so good for externally-updated macros) so I suggest using AS_IF.

Hope that helps,
  Nick

Re: [sr #110215] AC_EGREP_HEADER appears to be broken in master

[Ross Burton]

On Mon, 23 Mar 2020 at 23:20, Nick Bowler  wrote:
> Can you expand more on what is failing for you?  I just copy+pasted the
> above code into the following configure script:

I did a bit more digging.  At no point is autoconf looking for egrep
for some reason with master.  Specifically these lines are missing
when ran with autoconf master:

checking for grep that handles long lines and -e... /scratch/poky/hosttools/grep
checking for egrep... /scratch/poky/hosttools/grep -E

And echoing $EGREP before the test shows that it isn't set.

This is odd because AC_EGREP_CPP which is actually doing the work
should be searching for it:

AC_DEFUN([AC_EGREP_CPP],
[AC_LANG_PREPROC_REQUIRE()dnl
AC_REQUIRE([AC_PROG_EGREP])dnl
...

Looking at the generated configure, some code isn't being executed in
the right place.  The first instance of the AC_EGREP* calls are
earlier in the configure.ac, like this:

AC_CHECK_FUNC(statvfs,[HAVE_STATVFS=yes])
dnl Arg, linux and bsd put their statfs function in different places
if test x"$HAVE_STATVFS" != x"yes"; then
   AC_EGREP_HEADER(statfs,sys/vfs.h,[AC_DEFINE(HAVE_VFS_H)],[
   
AC_EGREP_HEADER(statfs,sys/mount.h,[AC_DEFINE(HAVE_MOUNT_H)],[AC_MSG_ERROR(failed:
Need statvfs)])
   ])
fi
(and later looks for h_errno then fails)

And the generated code does this:

if test x"$HAVE_STATVFS" != x"yes"; then
{ printf "%s\n" "$as_me:${as_lineno-$LINENO}: checking for grep that
handles long lines and
-e" >&5
printf %s "checking for grep that handles long lines and -e... " >&6; }
...

So the search for egrep only happens if statvfs isn't found by
AC_CHECK_FUNC.  My understanding is that this isn't how AC_REQUIRE
should be working, right?

Ross