[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: autoconf-2.69c released [beta]
From: |
Gavin Smith |
Subject: |
Re: autoconf-2.69c released [beta] |
Date: |
Sun, 27 Sep 2020 10:44:00 +0100 |
User-agent: |
Mutt/1.9.4 (2018-02-28) |
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
Re: autoconf-2.69c released [beta], Bob Friesenhahn, 2020/09/27
Re: autoconf-2.69c released [beta], Gavin Smith, 2020/09/27