Re: [sr #110215] AC_EGREP_HEADER appears to be broken in master
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
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
Re: [sr #110215] AC_EGREP_HEADER appears to be broken in master
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
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
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
Re: [sr #110215] AC_EGREP_HEADER appears to be broken in master
On 2020-03-23, Ross Burton wrote: > apt 1.2.31 builds fine with autoconf 2.69. With git master: > > | checking for h_errno... configure: error: "not found." > > That code is: > > dnl HP-UX needs -d_XOPEN_SOURCE_EXTENDED for h_errno > AC_MSG_CHECKING(for h_errno) > AC_EGREP_HEADER(h_errno, netdb.h, [AC_MSG_RESULT(normal)], >[CPPFLAGS="$CPPFLAGS -D_XOPEN_SOURCE_EXTENDED" > AC_EGREP_HEADER(h_errno, netdb.h, >[AC_MSG_RESULT(needs _XOPEN_SOURCE_EXTENDED)], >[AC_MSG_ERROR("not found.")]) >]) > > Obviously this is horrible, but it's out there. Can you expand more on what is failing for you? I just copy+pasted the above code into the following configure script: % cat >configure.ac <<'EOF' AC_INIT([test], [0]) dnl HP-UX needs -d_XOPEN_SOURCE_EXTENDED for h_errno AC_MSG_CHECKING(for h_errno) AC_EGREP_HEADER(h_errno, netdb.h, [AC_MSG_RESULT(normal)], [CPPFLAGS="$CPPFLAGS -D_XOPEN_SOURCE_EXTENDED" AC_EGREP_HEADER(h_errno, netdb.h, [AC_MSG_RESULT(needs _XOPEN_SOURCE_EXTENDED)], [AC_MSG_ERROR("not found.")]) ]) AC_OUTPUT EOF This seems to work perfectly fine with current autoconf master (ignoring the slightly mangled output due to the example being a bit contrived): % autoconf --version autoconf (GNU Autoconf) 2.69.209-8a09 [...] % autoconf % cat >netdb.h <<'EOF' #if GATE && _XOPEN_SOURCE_EXTENDED int h_errno; #endif EOF % ./configure CPPFLAGS='-I.' [...] configure: error: "not found." % ./configure CPPFLAGS='-I. -DGATE' [...] needs _XOPEN_SOURCE_EXTENDED % ./configure CPPFLAGS='-I. -DGATE -D_XOPEN_SOURCE_EXTENDED' [...] normal Which appears to be exactly as expected for this configure test. Cheers, Nick