Re: autoconf-2.69c released [beta]

[Gavin Smith]

On Sat, Sep 26, 2020 at 07:20:40PM -0700, Paul Eggert wrote:
> On 9/26/20 10:47 AM, Zack Weinberg wrote:
> 
> > > Would it be right to say that this should be changed in Gnulib,
> > > otherwise any project using that file with Gnulib will have errors
> > > from the new autoconf?
> > 
> > Yes, indeed.  All of the Gnulib and Autoconf Macro Archive macros need
> > to be checked for problems like this.  I'm cc:ing gnulib-bugs.
> 
> Thanks for reporting that. I installed the attached patch into Gnulib; it
> works for me on simple tests (I did reproduce the bug).
> 
> Gavin, could you please give the latest Gnulib a try?

Thank you, that does resolve that warning.

There are also warnings about AC_PROG_CC_STDC, AC_HELP_STRING, 
AC_HEADER_STDC, and $as_echo_n from other Gnulib files:

%

AC_PROG_CC_STDC from stdarg.m4 (via gl_PROG_CC_C99 in gnulib-common.m4):

# gl_PROG_CC_C99
# Modifies the value of the shell variable CC in an attempt to make $CC
# understand ISO C99 source code.
# This is like AC_PROG_CC_C99, except that
# - AC_PROG_CC_C99 does not mix well with AC_PROG_CC_STDC
#   <https://lists.gnu.org/r/bug-gnulib/2011-09/msg00367.html>,
#   but many more packages use AC_PROG_CC_STDC than AC_PROG_CC_C99
#   <https://lists.gnu.org/r/bug-gnulib/2011-09/msg00441.html>.
# Remaining problems:
# - When AC_PROG_CC_STDC is invoked twice, it adds the C99 enabling options
#   to CC twice
#   <https://lists.gnu.org/r/bug-gnulib/2011-09/msg00431.html>.
# - AC_PROG_CC_STDC is likely to change now that C11 is an ISO standard.
AC_DEFUN([gl_PROG_CC_C99],
[
  dnl Change that version number to the minimum Autoconf version that supports
  dnl mixing AC_PROG_CC_C99 calls with AC_PROG_CC_STDC calls.
  m4_version_prereq([9.0],
    [AC_REQUIRE([AC_PROG_CC_C99])],
    [AC_REQUIRE([AC_PROG_CC_STDC])])
])

I'll leave it to someone else to try to fix this.

%

AC_HELP_STRING from threadlib.m4.  Also used in libgcrypt.m4.  Running 
autoupdate on those files and editing the result gives the patch I've 
attached.

%

$as_echo_n is used in gnulib-common.m4 around a call to AC_CACHE_VAL:

# gl_CACHE_VAL_SILENT(cache-id, command-to-set-it)
# is like AC_CACHE_VAL(cache-id, command-to-set-it), except that it does not
# output a spurious "(cached)" mark in the midst of other configure output.
# This macro should be used instead of AC_CACHE_VAL when it is not surrounded
# by an AC_MSG_CHECKING/AC_MSG_RESULT pair.
AC_DEFUN([gl_CACHE_VAL_SILENT],
[
  saved_as_echo_n="$as_echo_n"
  as_echo_n=':'
  AC_CACHE_VAL([$1], [$2])
  as_echo_n="$saved_as_echo_n"
])

AC_CACHE_VAL calls _AS_ECHO_N which is defined in m4sh.sh from autoconf.  
The as_echo_n shell variable is not referred to at all, so this 
redefinition appears to be ineffectual.  gl_CACHE_VAL_SILENT is not used 
from gnulib-common.m4 itself but is used from a handful of other 
modules.  It is used in the stdarg module, but the issue of spurious 
output only arises if the "va_copy" function was not found.
The other files using gl_CACHE_VAL_SILENT were

floorf.m4, floorl.m4, floor.m4, ceilf.m4, ceilr.m4, ceil.m4

but I haven't tested whether these can produce spurious output.

%

I am going to try to run autoupdate on the other gnulib m4 files and see 
what happens.

AS_HELP_STRING.diff
Description: Text Data