Re: autoconf-2.69c released [beta]

[Eric Blake]

On 9/30/20 8:41 AM, Zack Weinberg wrote:

>> Most probably either 'git-version-gen' or some use of 'git describe'
>> can achieve this.
> 
> I just built autoconf (the program) from a completely clean checkout
> of git trunk, which is currently two commits after the v2.69c tag, and
> it identified itself as "autoconf (GNU Autoconf) 2.69c.2-04d14".  So
> it appears to me that what you suggest, already happens.
> 
> However, then I checked out git commit
> 14265094af1614d9e359550ca4a4939e590a5dba and rebuilt the tree, and it
> continued to identify itself as version 2.69c.2-04d14.  I had to run
> `git clean -xdf` and re-autoreconf before it would start identifying
> itself as 2.69b.67-14265.  So there *is* a bug somewhere in the build
> process, where it fails to notice that the value of @VERSION@ ought to
> change.  Perhaps that's how Paul got 2.69.301-14265.

Less of a bug and more an intentional thing.  When developing autoconf,
you don't want to have to frequently regenerate the world just because
of a version number change.  So the documented procedures for
maintainers is that you have to autoreconf twice: the first time to get
an autoconf that learns a version number for future output, but where
generated files still have a version number inherited from whatever
version of autoconf you bootstrapped with; the second time with the
just-built autoconf so that all version numbers appear the same (both in
generated comments and in what the second-built autoconf will produce).

Ideas on streamlining that are welcome, but as we at least have a
documented procedure (even if it is multi-step), it's not essential to
fix before 2.70.

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



signature.asc
Description: OpenPGP digital signature

Re: autoconf-2.69c released [beta]

[Zack Weinberg]

On Sun, Sep 27, 2020 at 7:10 PM Bruno Haible  wrote:
>
> Paul Eggert wrote:
> > > I don't know where you got this magic number 301-14265 from.
> >
> > I got it by checking out the then-current commit of Autoconf from Savannah 
> > git,
> > and building from that.
> >
> > Presumably doing the right thing here would mean a fix to Autoconf's
> > m4_version_prereq macro, not to Gnulib. m4_version_prereq should do the 
> > right
> > thing for the per-commit version numbers that Autoconf itself uses.
>
> But m4_version_prereq can not know whether version 2.69.345 is before or
> after the prerelease 2.69e.
>
> I think the real fix is therefore to change the Autoconf build system
> so that instead of 2.69.301-14265 it would produce 2.69b.67-14265.
> Then m4_version_prereq would know that this was between 2.69b and 2.69c.
>
> Most probably either 'git-version-gen' or some use of 'git describe'
> can achieve this.

I just built autoconf (the program) from a completely clean checkout
of git trunk, which is currently two commits after the v2.69c tag, and
it identified itself as "autoconf (GNU Autoconf) 2.69c.2-04d14".  So
it appears to me that what you suggest, already happens.

However, then I checked out git commit
14265094af1614d9e359550ca4a4939e590a5dba and rebuilt the tree, and it
continued to identify itself as version 2.69c.2-04d14.  I had to run
`git clean -xdf` and re-autoreconf before it would start identifying
itself as 2.69b.67-14265.  So there *is* a bug somewhere in the build
process, where it fails to notice that the value of @VERSION@ ought to
change.  Perhaps that's how Paul got 2.69.301-14265.

zw

Re: autoconf-2.69c released [beta]

[Bruno Haible]

Paul Eggert wrote:
> > I don't know where you got this magic number 301-14265 from.
> 
> I got it by checking out the then-current commit of Autoconf from Savannah 
> git, 
> and building from that.
> 
> Presumably doing the right thing here would mean a fix to Autoconf's 
> m4_version_prereq macro, not to Gnulib. m4_version_prereq should do the right 
> thing for the per-commit version numbers that Autoconf itself uses.

But m4_version_prereq can not know whether version 2.69.345 is before or
after the prerelease 2.69e.

I think the real fix is therefore to change the Autoconf build system
so that instead of 2.69.301-14265 it would produce 2.69b.67-14265.
Then m4_version_prereq would know that this was between 2.69b and 2.69c.

Most probably either 'git-version-gen' or some use of 'git describe'
can achieve this.

Bruno

Re: autoconf-2.69c released [beta]

[Paul Eggert]

On 9/27/20 2:55 PM, Bruno Haible wrote:

I don't know where you got this magic number 301-14265 from.


I got it by checking out the then-current commit of Autoconf from Savannah git, 
and building from that.


Presumably doing the right thing here would mean a fix to Autoconf's 
m4_version_prereq macro, not to Gnulib. m4_version_prereq should do the right 
thing for the per-commit version numbers that Autoconf itself uses.

Re: autoconf-2.69c released [beta]

[Bruno Haible]

Hi Paul,

I had been wondering why my patch with m4_version_prereq([2.70], ...) was
not effective, when you pointed me to the version numbering :)

> we need to test it with Autoconf prereleases too. 
> There are some longstanding "m4_version_prereq([2.70], ...)" calls in Gnulib 
> that should probably be changed to "m4_version_prereq([2.69.301-14265], ...)" 
> now, before Autoconf 2.70 comes out.

This should do it.


2020-09-27  Bruno Haible  

Enable testing of prereleases of Autoconf 2.70.
Suggested by Paul Eggert in
.
* m4/alloca.m4 (_AC_LIBOBJ_ALLOCA): Test for Autoconf >= 2.69c, not
>= 2.70.
* m4/largefile.m4 (AC_SYS_LARGEFILE): Likewise.
* m4/pid_t.m4 (AC_TYPE_PID_T): Likewise.
* m4/sys_types_h.m4 (AC_HEADER_MAJOR): Likewise.

diff --git a/m4/alloca.m4 b/m4/alloca.m4
index d841489..619959b 100644
--- a/m4/alloca.m4
+++ b/m4/alloca.m4
@@ -1,4 +1,4 @@
-# alloca.m4 serial 18
+# alloca.m4 serial 19
 dnl Copyright (C) 2002-2004, 2006-2007, 2009-2020 Free Software Foundation,
 dnl Inc.
 dnl This file is free software; the Free Software Foundation
@@ -50,10 +50,10 @@ AC_DEFUN([gl_FUNC_ALLOCA],
 # STACK_DIRECTION is already handled by AC_FUNC_ALLOCA.
 AC_DEFUN([gl_PREREQ_ALLOCA], [:])
 
-m4_version_prereq([2.70], [], [
+m4_version_prereq([2.69c], [], [
 
 # This works around a bug in autoconf <= 2.68 and has simplifications
-# from 2.70.  See:
+# from 2.69c.  See:
 # https://lists.gnu.org/r/bug-gnulib/2011-06/msg00277.html
 # 
https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=6cd9f12520b0d6f76d3230d7565feba1ecf29497
 # 
https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=15edf7fd8094fd14a89d9891dd72a9624762597a
diff --git a/m4/largefile.m4 b/m4/largefile.m4
index f4c5d3a..2562d06 100644
--- a/m4/largefile.m4
+++ b/m4/largefile.m4
@@ -25,7 +25,7 @@ AC_DEFUN([gl_SET_LARGEFILE_SOURCE],
 # The following implementation works around a problem in autoconf <= 2.69;
 # AC_SYS_LARGEFILE does not configure for large inodes on Mac OS X 10.5,
 # or configures them incorrectly in some cases.
-m4_version_prereq([2.70], [] ,[
+m4_version_prereq([2.69c], [] ,[
 
 # _AC_SYS_LARGEFILE_TEST_INCLUDES
 # ---
@@ -115,7 +115,7 @@ if test "$enable_largefile" != no; then
   fi
 fi
 ])# AC_SYS_LARGEFILE
-])# m4_version_prereq 2.70
+])# m4_version_prereq 2.69c
 
 # Enable large files on systems where this is implemented by Gnulib, not by the
 # system headers.
diff --git a/m4/pid_t.m4 b/m4/pid_t.m4
index 4fb9c7a..3eb7916 100644
--- a/m4/pid_t.m4
+++ b/m4/pid_t.m4
@@ -1,11 +1,11 @@
-# pid_t.m4 serial 2
+# pid_t.m4 serial 3
 dnl Copyright (C) 2020 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
 dnl with or without modifications, as long as this notice is preserved.
 
 # The following implementation works around a problem in autoconf <= 2.69.
-m4_version_prereq([2.70], [] ,[
+m4_version_prereq([2.69c], [] ,[
 
 dnl Define pid_t if the headers don't define it.
 AC_DEFUN([AC_TYPE_PID_T],
diff --git a/m4/sys_types_h.m4 b/m4/sys_types_h.m4
index be918dc..419b857 100644
--- a/m4/sys_types_h.m4
+++ b/m4/sys_types_h.m4
@@ -1,4 +1,4 @@
-# sys_types_h.m4 serial 9
+# sys_types_h.m4 serial 10
 dnl Copyright (C) 2011-2020 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -37,7 +37,7 @@ AC_DEFUN([gl_SYS_TYPES_H_DEFAULTS],
 # This works around a buggy version in autoconf <= 2.69.
 # See 
 
-m4_version_prereq([2.70], [], [
+m4_version_prereq([2.69c], [], [
 
 # This is taken from the following Autoconf patch:
 # 
https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=e17a30e987d7ee695fb4294a82d987ec3dc9b974

Re: autoconf-2.69c released [beta]

[Bruno Haible]

[CCing Autoconf list again]

Paul Eggert wrote:
> I am assuming that "m4_version_prereq([2.69.301-14265], ...)" does the right 
> thing with Autoconf beta version numbers; if not, that's an Autoconf bug that 
> should get fixed

Well, I don't know where you got this magic number 301-14265 from.

In my tests with version 2.69c,
  m4_version_prereq([2.70], NEW, OLD)
picked the OLD code, whereas
  m4_version_prereq([2.69c], NEW, OLD)
picked the NEW code.

The version comparison code (see m4sugar.m4, macro m4_version_unletter) seems
to handle prerelease version numbers fine.

In a git checkout of the Autoconf repository, when I run
  build-aux/git-version-gen .tarball-version
it prints
  2.69c.2-04d14

As far as I can see, versions of the form 2.69.xx-yyy will all be considered
smaller than even the first prerelease (2.69a); so that's probably not a
desirable way to designate intermediate versions between 2.69b and 2.69d.

Bruno

Re: autoconf-2.69c released [beta]

[Bruno Haible]

Gavin Smith wrote:
> 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
> #   ,
> #   but many more packages use AC_PROG_CC_STDC than AC_PROG_CC_C99
> #   .
> # Remaining problems:
> # - When AC_PROG_CC_STDC is invoked twice, it adds the C99 enabling options
> #   to CC twice
> #   .
> # - 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.

1) We don't need to care about Autoconf versions any more that didn't have
   AC_PROG_CC_C99. Gnulib assumes Autoconf >= 2.64.

2) What does it mean that "AC_PROG_CC_C99 does not mix well with
   AC_PROG_CC_STDC", as stated in
   ?

   I did a couple of tests with Autoconf 2.64; the results with 2.69 are the
   same.

   A configure script that contains
 AC_PROG_CC
 AC_PROG_CC_STDC
 AC_PROG_CC_C99
   produces
 - with CC="gcc-version 4.2.4":
   S["CC"]="gcc-version 4.2.4 -std=gnu99 -std=gnu99"
 - on AIX 7.1 with CC="xlc -qthreaded -qtls":
   S["CC"]="xlc -qthreaded -qtls"
 - on Solaris 10 with CC="cc -O":
   S["CC"]="cc -O -xc99=all -xc99=all"

   A configure script that contains
 AC_PROG_CC
 AC_PROG_CC_C99
 AC_PROG_CC_STDC
   produces
 - with CC="gcc-version 4.2.4":
   S["CC"]="gcc-version 4.2.4 -std=gnu99 -std=gnu99"
 - on AIX 7.1 with CC="xlc -qthreaded -qtls":
   S["CC"]="xlc -qthreaded -qtls"
 - on Solaris 10 with CC="cc -O":
   S["CC"]="cc -O -xc99=all -xc99=all"

   Typical configure output looks like this:
 checking whether we are using the GNU C compiler... yes
 checking whether gcc-version 4.2.4 accepts -g... yes
 checking for gcc-version 4.2.4 option to accept ISO C89... none needed
 checking for style of include used by make... GNU
 checking dependency style of gcc-version 4.2.4... none
 checking for gcc-version 4.2.4 option to accept ISO C99... -std=gnu99
 checking for gcc-version 4.2.4 -std=gnu99 option to accept ISO C99... 
(cached) -std=gnu99
 checking for gcc-version 4.2.4 -std=gnu99 -std=gnu99 option to accept ISO 
Standard C... (cached) -std=gnu99

   So, this works fine. Only a cosmetic problem.

   The doubling of the option does not occur in GCC versions that support C99
   by default, namely in GCC >= 5. So, few people will encounter this cosmetic
   problem.

So, AC_PROG_CC_C99 can be used in place of AC_PROG_CC_STDC always.
But with Autoconf 2.69c, this produces a warning:
  warning: The macro `AC_PROG_CC_C99' is obsolete.

I'm therefore committing this fix:


2020-09-27  Bruno Haible  

Avoid "warning: The macro `AC_PROG_CC_STDC' is obsolete".
Reported by Gavin Smith  in
.
* m4/gnulib-common.m4 (gl_PROG_CC_C99): Use AC_PROG_CC_C99 or
AC_PROG_CC, depending on the Autoconf version.

diff --git a/m4/gnulib-common.m4 b/m4/gnulib-common.m4
index a036454..ddf9e69 100644
--- a/m4/gnulib-common.m4
+++ b/m4/gnulib-common.m4
@@ -1,4 +1,4 @@
-# gnulib-common.m4 serial 61
+# gnulib-common.m4 serial 62
 dnl Copyright (C) 2007-2020 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -483,23 +483,17 @@ AC_DEFUN([gl_FEATURES_H],
 # 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
-#   ,
-#   but many more packages use AC_PROG_CC_STDC than AC_PROG_CC_C99
-#   .
-# Remaining problems:
-# - When AC_PROG_CC_STDC is invoked twice, it adds the C99 enabling options
-#   to CC twice
-#   .
-# - 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],
-

Re: autoconf-2.69c released [beta]

[Bruno Haible]

Gavin Smith wrote:
> %
> 
> 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'm committing these patches, for these two problems.


2020-09-27  Gavin Smith  

Avoid "warning: The macro `AC_HELP_STRING' is obsolete".
* m4/threadlib.m4 (gl_THREADLIB_EARLY_BODY): Use AS_HELP_STRING instead
of AC_HELP_STRING.
* m4/libgcrypt.m4 (AM_PATH_LIBGCRYPT): Likewise.

2020-09-27  Bruno Haible  

Avoid "warning: $as_echo_n is obsolete" from autoconf 2.69c.
Reported by Gavin Smith  in
.
* m4/gnulib-common.m4 (gl_CACHE_VAL_SILENT): Use gl_SILENT.

>From a20f05df0897a66fcfca7637e9dd84722d65 Mon Sep 17 00:00:00 2001
From: Bruno Haible 
Date: Sun, 27 Sep 2020 21:03:24 +0200
Subject: [PATCH 1/2] Avoid "warning: $as_echo_n is obsolete" from autoconf
 2.69c.

Reported by Gavin Smith  in
.
* m4/gnulib-common.m4 (gl_CACHE_VAL_SILENT): Use gl_SILENT.
---
 ChangeLog   | 7 +++
 m4/gnulib-common.m4 | 9 -
 2 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index ec6ab91..43e84b5 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,12 @@
 2020-09-27  Bruno Haible  
 
+	Avoid "warning: $as_echo_n is obsolete" from autoconf 2.69c.
+	Reported by Gavin Smith  in
+	.
+	* m4/gnulib-common.m4 (gl_CACHE_VAL_SILENT): Use gl_SILENT.
+
+2020-09-27  Bruno Haible  
+
 	extensions: Simplify last commit.
 	* m4/extensions.m4 (gl_USE_SYSTEM_EXTENSIONS): Don't require
 	AC_GNU_SOURCE ever.
diff --git a/m4/gnulib-common.m4 b/m4/gnulib-common.m4
index 57343e4..a036454 100644
--- a/m4/gnulib-common.m4
+++ b/m4/gnulib-common.m4
@@ -1,4 +1,4 @@
-# gnulib-common.m4 serial 60
+# gnulib-common.m4 serial 61
 dnl Copyright (C) 2007-2020 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -653,10 +653,9 @@ AC_DEFUN([gl_SILENT],
 # 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"
+  gl_SILENT([
+AC_CACHE_VAL([$1], [$2])
+  ])
 ])
 
 dnl Expands to some code for use in .c programs that, on native Windows, defines
-- 
2.7.4

>From d1f529d63b71c25616269b2ed2dc429adc1b586d Mon Sep 17 00:00:00 2001
From: Gavin Smith 
Date: Sun, 27 Sep 2020 21:06:51 +0200
Subject: [PATCH 2/2] Avoid "warning: The macro `AC_HELP_STRING' is obsolete".

* m4/threadlib.m4 (gl_THREADLIB_EARLY_BODY): Use AS_HELP_STRING instead
of AC_HELP_STRING.
* m4/libgcrypt.m4 (AM_PATH_LIBGCRYPT): Likewise.
---
 ChangeLog   | 7 +++
 m4/libgcrypt.m4 | 6 +++---
 m4/threadlib.m4 | 6 +++---
 3 files changed, 13 insertions(+), 6 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 43e84b5..428187f 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2020-09-27  Gavin Smith  
+
+	Avoid "warning: The macro `AC_HELP_STRING' is obsolete".
+	* m4/threadlib.m4 (gl_THREADLIB_EARLY_BODY): Use AS_HELP_STRING instead
+	of AC_HELP_STRING.
+	* m4/libgcrypt.m4 (AM_PATH_LIBGCRYPT): Likewise.
+
 2020-09-27  Bruno Haible  
 
 	Avoid "warning: $as_echo_n is obsolete" from autoconf 2.69c.
diff --git a/m4/libgcrypt.m4 b/m4/libgcrypt.m4
index f56cc1b..19d514f 100644
--- a/m4/libgcrypt.m4
+++ b/m4/libgcrypt.m4
@@ -1,5 +1,5 @@
 # libgcrypt.m4 - Autoconf macros to detect libgcrypt
-# Copyright (C) 2002, 2003, 2004, 2011, 2014, 2018 g10 Code GmbH
+# Copyright (C) 2002, 2003, 2004, 

Re: autoconf-2.69c released [beta]

[Paul Eggert]

On 9/27/20 7:03 AM, Bruno Haible wrote:


I'll look into these today.
Thanks for looking into it. Before I saw your email I had come up with the 
attached patches but I will hold off on installing them as I don't want to get 
in your way.


The "m4_version_prereq([2.69.301-14265], ...)" in one of the patches indicates 
some of the portability problems here. Gnulib needs to work with Autoconf 2.69 
and earlier (obviously), but we need to test it with Autoconf prereleases too. 
There are some longstanding "m4_version_prereq([2.70], ...)" calls in Gnulib 
that should probably be changed to "m4_version_prereq([2.69.301-14265], ...)" 
now, before Autoconf 2.70 comes out.


I am assuming that "m4_version_prereq([2.69.301-14265], ...)" does the right 
thing with Autoconf beta version numbers; if not, that's an Autoconf bug that 
should get fixed
diff --git a/m4/gnulib-common.m4 b/m4/gnulib-common.m4
index 57343e440..4443a99ce 100644
--- a/m4/gnulib-common.m4
+++ b/m4/gnulib-common.m4
@@ -1,4 +1,4 @@
-# gnulib-common.m4 serial 60
+# gnulib-common.m4 serial 61
 dnl Copyright (C) 2007-2020 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -483,7 +483,11 @@ AC_DEFUN([gl_FEATURES_H],
 # 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
+# This macro's implementation is not quite right, since it attempts to
+# use the latest version of the C standard instead of using C99 only.
+# So far there has seemed little motivation to fix this, as later standards
+# have mostly been extensions to C99.
+# With Autoconf 2.69 and earlier this is like AC_PROG_CC_C99, except that
 # - AC_PROG_CC_C99 does not mix well with AC_PROG_CC_STDC
 #   ,
 #   but many more packages use AC_PROG_CC_STDC than AC_PROG_CC_C99
@@ -495,10 +499,8 @@ AC_DEFUN([gl_FEATURES_H],
 # - 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])],
+  m4_version_prereq([2.69.301-14265], dnl Change to 2.70 when 2.70 comes out.
+[AC_REQUIRE([AC_PROG_CC])],
 [AC_REQUIRE([AC_PROG_CC_STDC])])
 ])
 
diff --git a/m4/malloc.m4 b/m4/malloc.m4
index c1f8ea32f..c6d814220 100644
--- a/m4/malloc.m4
+++ b/m4/malloc.m4
@@ -15,7 +15,7 @@ AC_DEFUN([_AC_FUNC_MALLOC_IF],
 [ac_cv_func_malloc_0_nonnull],
 [AC_RUN_IFELSE(
[AC_LANG_PROGRAM(
-  [[#if defined STDC_HEADERS || defined HAVE_STDLIB_H
+  [[#ifdef HAVE_STDLIB_H
 # include 
 #else
 char *malloc ();
diff --git a/m4/realloc.m4 b/m4/realloc.m4
index 85b8f874f..561e98823 100644
--- a/m4/realloc.m4
+++ b/m4/realloc.m4
@@ -15,7 +15,7 @@ AC_DEFUN([_AC_FUNC_REALLOC_IF],
 [ac_cv_func_realloc_0_nonnull],
 [AC_RUN_IFELSE(
[AC_LANG_PROGRAM(
-  [[#if defined STDC_HEADERS || defined HAVE_STDLIB_H
+  [[#ifdef HAVE_STDLIB_H
 # include 
 #else
 char *realloc ();

Re: autoconf-2.69c released [beta]

[Bruno Haible]

Gavin,

I'll look into these today. Thanks for the heads-up and analysis.

Bruno

Re: autoconf-2.69c released [beta]

[Bruno Haible]

I asked:
> Hi Paul,
> 
> > (I did reproduce the bug).
> 
> Have you reproduced the warning
>   "AC_COMPILE_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS"
> with autoconf 2.63 but not 2.64 ?

This is indeed the case. With this simple configure.ac
==
dnl This file is in the public domain.
dnl
dnl Configuration file - processed by autoconf.

AC_INIT([hello-c], [0])
AC_CONFIG_AUX_DIR([build-aux])
AC_CONFIG_SRCDIR([hello.c])
AM_INIT_AUTOMAKE

AC_PROG_CC
gl_USE_SYSTEM_EXTENSIONS
AC_CHECK_HEADERS([unistd.h])

AC_GNU_SOURCE

AC_CONFIG_FILES([Makefile])
AC_CONFIG_FILES([m4/Makefile])
AC_OUTPUT
==

and the previous definition of gl_USE_SYSTEM_EXTENSIONS, I observe (with
Automake 1.12.6):

* with autoconf 2.62 .. 2.63:

  configure.ac:14: warning: AC_USE_SYSTEM_EXTENSIONS invoked multiple times
  ../../lib/autoconf/specific.m4:331: AC_GNU_SOURCE is expanded from...
  configure.ac:14: the top level
  configure.ac:14: warning: AC_USE_SYSTEM_EXTENSIONS invoked multiple times
  ../../lib/autoconf/specific.m4:331: AC_GNU_SOURCE is expanded from...
  configure.ac:14: the top level

* with autoconf 2.64 .. 2.69b: no warnings

* with autoconf 2.69c:

  configure.ac:11: warning: The macro `AC_GNU_SOURCE' is obsolete.
  configure.ac:11: You should run autoupdate.
  ./lib/autoconf/specific.m4:312: AC_GNU_SOURCE is expanded from...
  m4/extensions.m4:178: gl_USE_SYSTEM_EXTENSIONS is expanded from...
  configure.ac:11: the top level
  configure.ac:14: warning: The macro `AC_GNU_SOURCE' is obsolete.
  configure.ac:14: You should run autoupdate.
  ./lib/autoconf/specific.m4:312: AC_GNU_SOURCE is expanded from...
  configure.ac:14: the top level
  configure.ac:11: warning: The macro `AC_GNU_SOURCE' is obsolete.
  configure.ac:11: You should run autoupdate.
  ./lib/autoconf/specific.m4:312: AC_GNU_SOURCE is expanded from...
  m4/extensions.m4:178: gl_USE_SYSTEM_EXTENSIONS is expanded from...
  configure.ac:11: the top level
  configure.ac:14: warning: The macro `AC_GNU_SOURCE' is obsolete.
  configure.ac:14: You should run autoupdate.
  ./lib/autoconf/specific.m4:312: AC_GNU_SOURCE is expanded from...
  configure.ac:14: the top level

Since in Gnulib we assume autoconf >= 2.64 (see NEWS entry from 2020-08-16)
we can remove this workaround.


2020-09-27  Bruno Haible  

extensions: Simplify last commit.
* m4/extensions.m4 (gl_USE_SYSTEM_EXTENSIONS): Don't require
AC_GNU_SOURCE ever.

diff --git a/m4/extensions.m4 b/m4/extensions.m4
index 22fdb03..3179080 100644
--- a/m4/extensions.m4
+++ b/m4/extensions.m4
@@ -1,4 +1,4 @@
-# serial 19  -*- Autoconf -*-
+# serial 20  -*- Autoconf -*-
 # Enable extensions on systems that normally disable them.
 
 # Copyright (C) 2003, 2006-2020 Free Software Foundation, Inc.
@@ -177,13 +177,5 @@ dnl configure.ac when using autoheader 2.62.
 # typically due to standards-conformance issues.
 AC_DEFUN_ONCE([gl_USE_SYSTEM_EXTENSIONS],
 [
-  dnl Require this macro before AC_USE_SYSTEM_EXTENSIONS.
-  dnl gnulib does not need it. But if it gets required by third-party macros
-  dnl after AC_USE_SYSTEM_EXTENSIONS is required, autoconf 2.62..2.63 emit a
-  dnl warning: "AC_COMPILE_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS".
-  dnl Note: We can do this only for one of the macros AC_AIX, AC_GNU_SOURCE,
-  dnl AC_MINIX. If people still use AC_AIX or AC_MINIX, they are out of luck.
-  m4_version_prereq([2.64], [], [AC_REQUIRE([AC_GNU_SOURCE])])
-
   AC_REQUIRE([AC_USE_SYSTEM_EXTENSIONS])
 ])

Re: autoconf-2.69c released [beta]

[Gavin Smith]

> diff --git a/ChangeLog b/ChangeLog
> index 8c06171aa..c77f19a68 100644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,3 +1,8 @@
> +2020-09-27  Gavin Smith  
> +
> + threadlib, libcrypt: use AS_HELP_MESSAGE instead of AC_HELP_MESSAGE.
> + * m4/threadlib.m4, m4/libgcrypt.m4: Update macro use.
> +

Sorry, this should have been AS_HELP_MESSAGE and AC_HELP_MESSAGE.

Re: autoconf-2.69c released [beta]

[Gavin Smith]

> -AC_PREREQ([2.60])
> +AC_PREREQ([2.69])

I left this in by mistake from autoupdate; I'd guess it should be left 
as 2.60.

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
#   ,
#   but many more packages use AC_PROG_CC_STDC than AC_PROG_CC_C99
#   .
# Remaining problems:
# - When AC_PROG_CC_STDC is invoked twice, it adds the C99 enabling options
#   to CC twice
#   .
# - 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.
commit f077b04f4f694059180a37d1720685b2a1bac544
Author: Gavin Smith 
Date:   Sun Sep 27 10:20:06 2020 +0100

AS_HELP_STRING

diff --git a/ChangeLog b/ChangeLog
index 8c06171aa..c77f19a68 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2020-09-27  Gavin Smith  
+
+	threadlib, libcrypt: use AS_HELP_MESSAGE instead of AC_HELP_MESSAGE.
+	* m4/threadlib.m4, m4/libgcrypt.m4: Update macro use.
+
 2020-09-26  Paul Eggert  
 
 	extensions: require AC_GNU_SOURCE only for <=2.63
diff --git a/m4/libgcrypt.m4 b/m4/libgcrypt.m4
index f56cc1bde..80947fbb6 100644
--- a/m4/libgcrypt.m4
+++ b/m4/libgcrypt.m4
@@ -1,5 +1,6 @@
 # libgcrypt.m4 - Autoconf macros to detect libgcrypt
 # Copyright (C) 2002, 2003, 2004, 2011, 2014, 2018 g10 Code GmbH
+# Copyright (C) 2020 Free Software Foundation
 #
 # This file is free software; as a special exception the author gives
 # unlimited permission to copy and/or distribute it, with or without
@@ -9,7 +10,6 @@
 # WITHOUT ANY WARRANTY, to the extent permitted by law; without even the
 # implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
 #
-# Last-changed: 2018-11-13
 
 
 dnl AM_PATH_LIBGCRYPT([MINIMUM-VERSION,
@@ -30,7 +30,7 @@ dnl
 AC_DEFUN([AM_PATH_LIBGCRYPT],
 [ AC_REQUIRE([AC_CANONICAL_HOST])
   AC_ARG_WITH(libgcrypt-prefix,
-AC_HELP_STRING([--with-libgcrypt-prefix=PFX],
+AS_HELP_STRING([--with-libgcrypt-prefix=PFX],
[prefix where LIBGCRYPT is installed (optional)]),
  libgcrypt_config_prefix="$withval", libgcrypt_config_prefix="")
   if test x"${LIBGCRYPT_CONFIG}" = x ; then
diff --git a/m4/threadlib.m4 b/m4/threadlib.m4
index 94441f680..352fb5e3e 100644
--- a/m4/threadlib.m4
+++ b/m4/threadlib.m4
@@ -6,7 +6,7 @@ dnl with 

Re: autoconf-2.69c released [beta]

[Bruno Haible]

Hi Paul,

> (I did reproduce the bug).

Have you reproduced the warning
  "AC_COMPILE_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS"
with autoconf 2.63 but not 2.64 ?

I'm asking because when I added that comment on 2009-01-25, the newest
released version at that moment was 2.63. So, unless you have verified
otherwise, it could very well be that this warning is still present with
newer versions.

Bruno

Re: autoconf-2.69c released [beta]

[Paul Eggert]

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?
>From 43710542d7b1ae457160355adc8cf50fe8070416 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Sat, 26 Sep 2020 19:18:08 -0700
Subject: [PATCH] extensions: require AC_GNU_SOURCE only for <=2.63
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Problem reported by Gavin Smith in:
https://lists.gnu.org/r/autoconf/2020-09/msg00012.html
* m4/extensions.m4 ([gl_USE_SYSTEM_EXTENSIONS]):
Require AC_GNU_SOURCE only for Autoconf 2.63 and earlier, since it
shouldn’t be needed after that, and Autoconf 2.70 complains about
it being obsolete.
---
 ChangeLog| 10 ++
 m4/extensions.m4 |  4 ++--
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index d5cabb487..8c06171aa 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,13 @@
+2020-09-26  Paul Eggert  
+
+	extensions: require AC_GNU_SOURCE only for <=2.63
+	Problem reported by Gavin Smith in:
+	https://lists.gnu.org/r/autoconf/2020-09/msg00012.html
+	* m4/extensions.m4 ([gl_USE_SYSTEM_EXTENSIONS]):
+	Require AC_GNU_SOURCE only for Autoconf 2.63 and earlier, since it
+	shouldn’t be needed after that, and Autoconf 2.70 complains about
+	it being obsolete.
+
 2020-09-26  Bruno Haible  
 
 	regex-tests: Make test more robust.
diff --git a/m4/extensions.m4 b/m4/extensions.m4
index d7c95effd..22fdb03e3 100644
--- a/m4/extensions.m4
+++ b/m4/extensions.m4
@@ -1,4 +1,4 @@
-# serial 18  -*- Autoconf -*-
+# serial 19  -*- Autoconf -*-
 # Enable extensions on systems that normally disable them.
 
 # Copyright (C) 2003, 2006-2020 Free Software Foundation, Inc.
@@ -183,7 +183,7 @@ AC_DEFUN_ONCE([gl_USE_SYSTEM_EXTENSIONS],
   dnl warning: "AC_COMPILE_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS".
   dnl Note: We can do this only for one of the macros AC_AIX, AC_GNU_SOURCE,
   dnl AC_MINIX. If people still use AC_AIX or AC_MINIX, they are out of luck.
-  AC_REQUIRE([AC_GNU_SOURCE])
+  m4_version_prereq([2.64], [], [AC_REQUIRE([AC_GNU_SOURCE])])
 
   AC_REQUIRE([AC_USE_SYSTEM_EXTENSIONS])
 ])
-- 
2.17.1

Re: autoconf-2.69c released [beta]

[Zack Weinberg]

On Sat, Sep 26, 2020 at 8:15 AM Gavin Smith  wrote:
> On Fri, Sep 25, 2020 at 9:07 PM Gavin Smith  wrote:
> >
> > > * Warnings about obsolete constructs are now on by default.
> > >   They can be turned off with '-Wno-obsolete'.
> > >
> >
> > I have tried building the git development version of Texinfo with
> > the new autoconf, but am deluged with warnings.  I get the following
> > warnings from autoconf:
> >
> > configure.ac:87: warning: The macro `AC_GNU_SOURCE' is obsolete.
> > configure.ac:87: You should run autoupdate.
> > ./lib/autoconf/specific.m4:312: AC_GNU_SOURCE is expanded from...
> > gnulib/m4/gnulib-comp.m4:34: gl_EARLY is expanded from...
> > configure.ac:87: the top level
>
> I found it hard to track down where the AC_GNU_SOURCE use was coming
> from, and the path "lib/autoconf/specific.m4" is incorrect for the
> file "specific.m4".

Yes, unfortunately, the m4 backtrace emitted by configure warnings
doesn't handle AC_REQUIREd macros correctly.  Fixing this is probably
not feasible for 2.70.

> By searching for the text AC_GNU_SOURCE in all
> project files as well as installed autoconf files, as well as looking
> at the log files under autom4te.cache, I suspect it is coming from the
> "extensions.m4" file from Gnulib. (I don't know why that file isn't
> named in the error messages, though.) This has the following
> definition:
>
> # gl_USE_SYSTEM_EXTENSIONS
> # 
> # Enable extensions on systems that normally disable them,
> # typically due to standards-conformance issues.
> AC_DEFUN_ONCE([gl_USE_SYSTEM_EXTENSIONS],
> [
>   dnl Require this macro before AC_USE_SYSTEM_EXTENSIONS.
>   dnl gnulib does not need it. But if it gets required by third-party macros
>   dnl after AC_USE_SYSTEM_EXTENSIONS is required, autoconf 2.62..2.63 emit a
>   dnl warning: "AC_COMPILE_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS".
>   dnl Note: We can do this only for one of the macros AC_AIX, AC_GNU_SOURCE,
>   dnl AC_MINIX. If people still use AC_AIX or AC_MINIX, they are out of luck.
>   AC_REQUIRE([AC_GNU_SOURCE])
>
>   AC_REQUIRE([AC_USE_SYSTEM_EXTENSIONS])
> ])
>
> 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.

zw