Re: autoconf-2.69c released [beta]

[Bob Friesenhahn]

On Wed, 30 Sep 2020, Zack Weinberg wrote:


In particular, the AC_*_IFELSE macros have been available since
version 2.55, which was released in 2002(!)


Well, this configure script was first implemented in 1996 to replace 
something called 'imake'.  I am sure that there must be many more 
things to improve in it since (given an existing huge work-load) I 
don't actively re-visit the Autoconf documentation and the script to 
see what should be changed to modernize it.  I do know that it should 
have a lot more quoting.



Under OpenIndiana I still get 6 test failures.


Are these test failures of GraphicsMagick's test suite, or of
autoconf's own test suite?  I don't have access to an OpenIndiana
system but I would still be interested in more detail.  If it's
autoconf's own testsuite, a tarball of `tests/testsuite.dir` in the
build tree is usually enough information for me to figure out what's
wrong.


These are Autoconf test suite failures.  You should still have access 
to an OpenIndiana system since I see that you last accessed my 
OpenIndiana system on August 4th!.  Access for yourself and Paul 
Eggert has not been taken away.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

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 2:03 PM Bob Friesenhahn
 wrote:
>
> Today I am trying autoconf-2.69c with GraphicsMagick's configure.ac
> and am only encountering utter failure.

It sounds like you already got a bunch of help and most of the
problems are resolved.  I just want to add a few notes:

- As other people have said, the result of running `autoupdate` is not
meant to be used as-is.  There are many cases where it can't
completely modernize the code, many problems it can't fix (e.g.
problems with quotation), and situations where it produces code that's
just plain wrong (e.g. when an obsolete macro is used via AC_REQUIRE).
It's meant to be a starting point only.

- autoupdate puts AC_PREREQ([its own version]) in the script because
it doesn't know how far back its replacements are good.  However, in
nearly all cases, its suggested replacement will work fine with 2.69.
In fact, the only exception I can think of right now is when it
inserts AC_CHECK_INCLUDES_DEFAULT, and that's a defensive measure that
you may be able to delete or replace with additional uses of
AC_CHECK_HEADERS.

In particular, the AC_*_IFELSE macros have been available since
version 2.55, which was released in 2002(!)

> Under OpenIndiana I still get 6 test failures.

Are these test failures of GraphicsMagick's test suite, or of
autoconf's own test suite?  I don't have access to an OpenIndiana
system but I would still be interested in more detail.  If it's
autoconf's own testsuite, a tarball of `tests/testsuite.dir` in the
build tree is usually enough information for me to figure out what's
wrong.

zw

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]

[Zack Weinberg]

On Tue, Sep 29, 2020 at 8:04 PM Russ Allbery  wrote:
>
> This is separate from the question of how Autoconf should handle old
> configure scripts and how autoupdate should work, but while you're
> manually making changes to macros anyway, you will probably be happier in
> the long run if you quote all arguments and make a habit of using AS_IF
> instead of open-coded shell if statements.
>
> # Test for C compiler __func__ support
> AS_IF([test "$ac_cv_have_C__func__" != 'yes'], [
> AC_CACHE_CHECK([for C compiler __func__ support], [ac_cv_have_C__func__],
> [AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]],
> [[const char *func=__func__;
> return (func != 0 ? 0 : 1);
> ]])],
> [ac_cv_have_C__func__='yes'],
> [ac_cv_have_C__func__='no'])])
>
> AS_IF([test "$ac_cv_have_C__func__" = 'yes'], [
>  AC_DEFINE([HAS_C__func__],[1],[Define if C compiler supports __func__])
> ])
> ])
>
> This will protect against a lot of edge cases.

Very much agree.  We have several reports already that the betas break
old scripts with insufficient quoting and/or open-coded if statements,
and all I can do about them is put dire warnings in NEWS, because
autoupdate can only act on obsolete _macro names_...

Also I want to point out that the AS_IF wrapping the AC_CACHE_CHECK is
unnecessary: AC_CACHE_CHECK does the same thing internally.

zw

Re: autoconf-2.69c released [beta]

[Russ Allbery]

Bob Friesenhahn  writes:

> Gavin, thanks very much for your help.  Just in case someone reads this
> discussion later, I found that there was a small syntax error in the
> above.  The following is what finally worked for me (a small change after
> ac_cv_have_C__func__='no'):

> # Test for C compiler __func__ support
> if test "$ac_cv_have_C__func__" != 'yes' ; then
> AC_CACHE_CHECK(for C compiler __func__ support, ac_cv_have_C__func__,
> [AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]],
> [[const char *func=__func__;
> return (func != 0 ? 0 : 1);
> ]])],
> [ac_cv_have_C__func__='yes'],
> [ac_cv_have_C__func__='no'])])

> if test "$ac_cv_have_C__func__" = 'yes' ; then
>  AC_DEFINE(HAS_C__func__,1,Define if C compiler supports __func__)
> fi
> fi

This is separate from the question of how Autoconf should handle old
configure scripts and how autoupdate should work, but while you're
manually making changes to macros anyway, you will probably be happier in
the long run if you quote all arguments and make a habit of using AS_IF
instead of open-coded shell if statements.

# Test for C compiler __func__ support
AS_IF([test "$ac_cv_have_C__func__" != 'yes'], [
AC_CACHE_CHECK([for C compiler __func__ support], [ac_cv_have_C__func__],
[AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]],
[[const char *func=__func__;
return (func != 0 ? 0 : 1);
]])],
[ac_cv_have_C__func__='yes'],
[ac_cv_have_C__func__='no'])])

AS_IF([test "$ac_cv_have_C__func__" = 'yes'], [
 AC_DEFINE([HAS_C__func__],[1],[Define if C compiler supports __func__])
])
])

This will protect against a lot of edge cases.

-- 
Russ Allbery (ea...@eyrie.org) 

Re: autoconf-2.69c released [beta]

[Bob Friesenhahn]

On Sun, 27 Sep 2020, Gavin Smith wrote:


That should be:

if test "$ac_cv_have_C__func__" != 'yes' ; then
AC_CACHE_CHECK(for C compiler __func__ support, ac_cv_have_C__func__,
[AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]],
[[const char *func=__func__;
return (func != 0 ? 0 : 1);
]])],
[ac_cv_have_C__func__='yes'],
[ac_cv_have_C__func__='no']])])

if test "$ac_cv_have_C__func__" = 'yes' ; then
AC_DEFINE(HAS_C__func__,1,Define if C compiler supports __func__)
fi
fi


Gavin, thanks very much for your help.  Just in case someone reads 
this discussion later, I found that there was a small syntax error in 
the above.  The following is what finally worked for me (a small 
change after ac_cv_have_C__func__='no'):


# Test for C compiler __func__ support
if test "$ac_cv_have_C__func__" != 'yes' ; then
AC_CACHE_CHECK(for C compiler __func__ support, ac_cv_have_C__func__,
[AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]],
[[const char *func=__func__;
return (func != 0 ? 0 : 1);
]])],
[ac_cv_have_C__func__='yes'],
[ac_cv_have_C__func__='no'])])

if test "$ac_cv_have_C__func__" = 'yes' ; then
 AC_DEFINE(HAS_C__func__,1,Define if C compiler supports __func__)
fi
fi

I now have the GraphicsMagick configure script updated and apparently 
working fine locally with Autoconf 2.69c.


There are still some deprecation warnings from an included m4 module.

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

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]

[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]

[Gavin Smith]

> Maybe it is a problem with changequote being used inside an argument to 
> a macro.  Does it work OK when you remove the changequote lines?
> 
> if test "$ac_cv_have_C__func__" != 'yes' ; then
> AC_CACHE_CHECK(for C compiler __func__ support, ac_cv_have_C__func__,
> [AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]],
> <<
> const char *func=__func__;
> return (func != 0 ? 0 : 1);
> >> ]])],
> [ac_cv_have_C__func__='yes'],
> [ac_cv_have_C__func__='no']])])
> 
> if test "$ac_cv_have_C__func__" = 'yes' ; then
>  AC_DEFINE(HAS_C__func__,1,Define if C compiler supports __func__)
> fi
> fi

That should be:

if test "$ac_cv_have_C__func__" != 'yes' ; then
AC_CACHE_CHECK(for C compiler __func__ support, ac_cv_have_C__func__,
[AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]],
[[const char *func=__func__;
return (func != 0 ? 0 : 1);
]])],
[ac_cv_have_C__func__='yes'],
[ac_cv_have_C__func__='no']])])

if test "$ac_cv_have_C__func__" = 'yes' ; then
 AC_DEFINE(HAS_C__func__,1,Define if C compiler supports __func__)
fi
fi

Re: autoconf-2.69c released [beta]

[Gavin Smith]

On Sun, Sep 27, 2020 at 01:56:06PM -0500, Bob Friesenhahn wrote:
> On Sun, 27 Sep 2020, Gavin Smith wrote:
> > 
> > It might help if you could post what the AC_TRY_COMPILE statements were
> > changed into.  If I understand correctly the definition in
> > autoconf/general.m4
> 
> That would certainly help and it is perhaps likely that there is some syntax
> weakness in the original.  See below.
> 
> Since the problem also occurs with Autoconf 2.69 autoupdate, that is what I
> use for the test case.
> 
> Input:
> 
> # Test for C compiler __func__ support
> if test "$ac_cv_have_C__func__" != 'yes' ; then
> AC_CACHE_CHECK(for C compiler __func__ support, ac_cv_have_C__func__,
> [AC_TRY_COMPILE(
> ,
> changequote(<<, >>)dnl
> <<
> const char *func=__func__;
> return (func != 0 ? 0 : 1);
> > > ,

For some reason there is an extra space in your email but I replicated 
the problem by deleting the space.

> changequote([, ])dnl
> ac_cv_have_C__func__='yes',
> ac_cv_have_C__func__='no')])
> 
> if test "$ac_cv_have_C__func__" = 'yes' ; then
>  AC_DEFINE(HAS_C__func__,1,Define if C compiler supports __func__)
> fi
> fi
> 
> After Autoconf 2.69 autoupdate:
> 
> # Test for C compiler __func__ support
> if test "$ac_cv_have_C__func__" != 'yes' ; then
> AC_CACHE_CHECK(for C compiler __func__ support, ac_cv_have_C__func__,
> [AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]], [[changequote(<<, >>)dnl
> <<
> const char *func=__func__;
> return (func != 0 ? 0 : 1);
> > > ]])],[changequote(, )dnl
> ac_cv_have_C__func__='yes'],[ac_cv_have_C__func__='no'])])
> 
> if test "$ac_cv_have_C__func__" = 'yes' ; then
>  AC_DEFINE(HAS_C__func__,1,Define if C compiler supports __func__)
> fi
> fi

Maybe it is a problem with changequote being used inside an argument to 
a macro.  Does it work OK when you remove the changequote lines?

if test "$ac_cv_have_C__func__" != 'yes' ; then
AC_CACHE_CHECK(for C compiler __func__ support, ac_cv_have_C__func__,
[AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]],
<<
const char *func=__func__;
return (func != 0 ? 0 : 1);
>> ]])],
[ac_cv_have_C__func__='yes'],
[ac_cv_have_C__func__='no']])])

if test "$ac_cv_have_C__func__" = 'yes' ; then
 AC_DEFINE(HAS_C__func__,1,Define if C compiler supports __func__)
fi
fi


Perhaps you could revert autoupdate's changes, try removing the 
changequote lines, check that the script still works, and then try 
autoupdate again and see if you have better results.

Re: autoconf-2.69c released [beta]

[Bob Friesenhahn]

On Sun, 27 Sep 2020, Gavin Smith wrote:


It might help if you could post what the AC_TRY_COMPILE statements were
changed into.  If I understand correctly the definition in
autoconf/general.m4


That would certainly help and it is perhaps likely that there is some 
syntax weakness in the original.  See below.


Since the problem also occurs with Autoconf 2.69 autoupdate, that is 
what I use for the test case.


Input:

# Test for C compiler __func__ support
if test "$ac_cv_have_C__func__" != 'yes' ; then
AC_CACHE_CHECK(for C compiler __func__ support, ac_cv_have_C__func__,
[AC_TRY_COMPILE(
,
changequote(<<, >>)dnl
<<
const char *func=__func__;
return (func != 0 ? 0 : 1);

,

changequote([, ])dnl
ac_cv_have_C__func__='yes',
ac_cv_have_C__func__='no')])

if test "$ac_cv_have_C__func__" = 'yes' ; then
 AC_DEFINE(HAS_C__func__,1,Define if C compiler supports __func__)
fi
fi

After Autoconf 2.69 autoupdate:

# Test for C compiler __func__ support
if test "$ac_cv_have_C__func__" != 'yes' ; then
AC_CACHE_CHECK(for C compiler __func__ support, ac_cv_have_C__func__,
[AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]], [[changequote(<<, >>)dnl
<<
const char *func=__func__;
return (func != 0 ? 0 : 1);

]])],[changequote(, )dnl

ac_cv_have_C__func__='yes'],[ac_cv_have_C__func__='no'])])

if test "$ac_cv_have_C__func__" = 'yes' ; then
 AC_DEFINE(HAS_C__func__,1,Define if C compiler supports __func__)
fi
fi

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: autoconf-2.69c released [beta]

[Bob Friesenhahn]

On Sun, 27 Sep 2020, Paul Eggert wrote:


On 9/27/20 11:23 AM, Bob Friesenhahn wrote:

Is 'autoupdate' supposed to be safe to use?


I would never trust the output of 'autoupdate', no. It's meant to be 
suggestions and/or indications of problems, and is not meant to be 
authoritative. Perhaps this should be stated more clearly in the 
documentation.


That was my recollection from long ago, but things change.  The 
Autoconf utilities recommend executing 'autoupdate'.


With 2.69 (and 2.69c), each one of my AC_TRY_COMPILE() statements was 
re-written into a form which blows m4's recursion limits.  Perhaps I 
have somehow formatted them incorrectly, but some of them have been 
working fine since perhaps even 1998.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: autoconf-2.69c released [beta]

[Gavin Smith]

On Sun, Sep 27, 2020 at 01:03:03PM -0500, Bob Friesenhahn wrote:
> Today I am trying autoconf-2.69c with GraphicsMagick's configure.ac and am
> only encountering utter failure.
> 
> A great many macros (still used to provide backward compatibility) are now
> declared as obsolete.  I ran 'autoupdate' and see that AC_TRY_COMPILE
> statements were changed to use new syntax.  The problem is that with the
> replacement code it inserted I get this m4 error:
> 
> libtoolize: found LT_INIT invocation
> m4:configure.ac:1045: recursion limit of 1024 exceeded, use -L to change it
> autom4te: error: /usr/gnu/bin/m4 failed with exit status: 1
> aclocal: error: echo failed with exit status: 1
> m4:configure.ac:1045: recursion limit of 1024 exceeded, use -L to change it
> autom4te: error: /usr/gnu/bin/m4 failed with exit status: 1
> autoheader: error: '/usr/local/bin/autom4te' failed with exit status: 1
> m4:configure.ac:1045: recursion limit of 1024 exceeded, use -L to change it
> autom4te: error: /usr/gnu/bin/m4 failed with exit status: 1

It might help if you could post what the AC_TRY_COMPILE statements were 
changed into.  If I understand correctly the definition in 
autoconf/general.m4

AU_DEFUN([AC_TRY_COMPILE],
[AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[$1]], [[$2]])], [$3], [$4])])

is used by autoupdate.  It would be a question of working out what is 
wrong with the new construction with AC_COMPILE_IF_ELSE.

> I am also concerned that the first active line after executing 'autoupdate'
> is this:
> 
> AC_PREREQ([2.69c])
> 
> Presumably this means that version 2.69c is required to re-autoconf the
> configure script.  I certainly could not impose this overwhelming burden on
> my users.  If the resulting output can not be used with the prevailing
> version (2.69) then I can not use it!  I don't see now a new release can
> obviate the stable release which preceded it and is still in primary use!

I'm fairly certain that autoupdate is just putting the current version 
of autoconf in there and it would work OK with an older version, 
certainly 2.69 but possibly older versions too.  Maybe the AC_PREREQ 
argument is not something that should be set automatically.

Re: autoconf-2.69c released [beta]

[Paul Eggert]

On 9/27/20 11:23 AM, Bob Friesenhahn wrote:

Is 'autoupdate' supposed to be safe to use?


I would never trust the output of 'autoupdate', no. It's meant to be suggestions 
and/or indications of problems, and is not meant to be authoritative. Perhaps 
this should be stated more clearly in the documentation.

Re: autoconf-2.69c released [beta]

[Bob Friesenhahn]

On Sun, 27 Sep 2020, Bob Friesenhahn wrote:


A great many macros (still used to provide backward compatibility) are now 
declared as obsolete.  I ran 'autoupdate' and see that AC_TRY_COMPILE 
statements were changed to use new syntax.  The problem is that with the 
replacement code it inserted I get this m4 error:


libtoolize: found LT_INIT invocation
m4:configure.ac:1045: recursion limit of 1024 exceeded, use -L to change


I see that if I use 'autoupdate' from 2.69 that it also produces a 
configure.ac which recurses.  Is 'autoupdate' supposed to be safe to 
use?


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: autoconf-2.69c released [beta]

[Bob Friesenhahn]

Today I am trying autoconf-2.69c with GraphicsMagick's configure.ac 
and am only encountering utter failure.


A great many macros (still used to provide backward compatibility) are 
now declared as obsolete.  I ran 'autoupdate' and see that 
AC_TRY_COMPILE statements were changed to use new syntax.  The problem 
is that with the replacement code it inserted I get this m4 error:


libtoolize: found LT_INIT invocation
m4:configure.ac:1045: recursion limit of 1024 exceeded, use -L to change it
autom4te: error: /usr/gnu/bin/m4 failed with exit status: 1
aclocal: error: echo failed with exit status: 1
m4:configure.ac:1045: recursion limit of 1024 exceeded, use -L to change it
autom4te: error: /usr/gnu/bin/m4 failed with exit status: 1
autoheader: error: '/usr/local/bin/autom4te' failed with exit status: 1
m4:configure.ac:1045: recursion limit of 1024 exceeded, use -L to change it
autom4te: error: /usr/gnu/bin/m4 failed with exit status: 1

I am also concerned that the first active line after executing 
'autoupdate' is this:


AC_PREREQ([2.69c])

Presumably this means that version 2.69c is required to re-autoconf 
the configure script.  I certainly could not impose this overwhelming 
burden on my users.  If the resulting output can not be used with the 
prevailing version (2.69) then I can not use it!  I don't see now a 
new release can obviate the stable release which preceded it and is 
still in primary use!


Under OpenIndiana I still get 6 test failures.

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

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

Re: autoconf-2.69c released [beta]

[Gavin Smith]

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". 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?

Re: autoconf-2.69c released [beta]

[Gavin Smith]

> * 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
configure.ac:87: warning: The macro `AC_PROG_CC_STDC' is obsolete.
configure.ac:87: You should run autoupdate.
gnulib/m4/std-gnu11.m4:476: AC_PROG_CC_STDC is expanded from...
gnulib/m4/gnulib-common.m4:496: gl_PROG_CC_C99 is expanded from...
gnulib/m4/gnulib-comp.m4:34: gl_EARLY is expanded from...
configure.ac:87: the top level
configure.ac:87: warning: The macro `AC_HELP_STRING' is obsolete.
configure.ac:87: You should run autoupdate.
./lib/autoconf/general.m4:203: AC_HELP_STRING is expanded from...
gnulib/m4/threadlib.m4:384: gl_THREADLIB_EARLY_BODY is expanded from...
gnulib/m4/threadlib.m4:377: gl_THREADLIB_EARLY is expanded from...
gnulib/m4/gnulib-comp.m4:34: gl_EARLY is expanded from...
configure.ac:87: the top level
configure.ac:90: warning: The macro `AC_HEADER_STDC' is obsolete.
configure.ac:90: You should run autoupdate.
./lib/autoconf/headers.m4:657: AC_HEADER_STDC is expanded from...
gnulib/m4/malloc.m4:9: _AC_FUNC_MALLOC_IF is expanded from...
gnulib/m4/eealloc.m4:13: gl_EEMALLOC is expanded from...
gnulib/m4/malloca.m4:8: gl_MALLOCA is expanded from...
gnulib/m4/gnulib-comp.m4:179: gl_INIT is expanded from...
configure.ac:90: the top level
configure.ac:90: warning: $as_echo_n is obsolete; use AS_ECHO_N(["message"]) 
instead
gnulib/m4/gnulib-common.m4:654: gl_CACHE_VAL_SILENT is expanded from...
gnulib/m4/stdarg.m4:10: gl_STDARG_H is expanded from...
gnulib/m4/gnulib-comp.m4:179: gl_INIT is expanded from...
configure.ac:90: the top level

I had run autoupdate, and fixed some of the warnings, but most of the 
warnings don't seem to be coming from the configure.ac in the package 
itself, but from gnulib.  I tried updating the gnulib files by running 
"gnulib-tool --add-import" but this didn't make any difference that I 
noticed.  Is there another way to refresh the gnulib files like 
"gnulib-common.m4" and so on?

I don't know if this is new for this pretest, as I didn't try any of the 
earlier pretests.

autoconf-2.69c released [beta]

[Zack Weinberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

We are pleased to announce beta release 2.69c of GNU Autoconf.

This release includes two months of bug fixes since the previous beta,
2.68b, and eight years of development work since the previous full
release, 2.69.  See below for the list of significant changes since
the previous beta.  See the NEWS file for a complete list of
significant changes since 2.69.

We tentatively plan to make the final release of Autoconf 2.70 at the
end of October 2020.  Please test this beta with your autoconf
scripts, and report any problems you find to the Savannah bug tracker:

   https://savannah.gnu.org/support/?func=additem=autoconf

Please also send general comments and feedback to .

Please also spread this announcement widely, so that as many Autoconf
users as possible hear about it.

Here are the compressed sources:
  https://alpha.gnu.org/gnu/autoconf/autoconf-2.69c.tar.gz   (2.0MB)
  https://alpha.gnu.org/gnu/autoconf/autoconf-2.69c.tar.xz   (1.3MB)

Here are the GPG detached signatures[*]:
  https://alpha.gnu.org/gnu/autoconf/autoconf-2.69c.tar.gz.sig
  https://alpha.gnu.org/gnu/autoconf/autoconf-2.69c.tar.xz.sig

Use a mirror for higher download bandwidth:
  https://www.gnu.org/order/ftp.html

[*] Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact.  First, be sure to download both the .sig file
and the corresponding tarball.  Then, run a command like this:

  gpg --verify autoconf-2.69c.tar.gz.sig

If that command fails because you don't have the required public key,
then run this command to import it:

  gpg --keyserver keys.gnupg.net --recv-keys 384F8E68AC65B0D5

and rerun the 'gpg --verify' command.

This release was bootstrapped with the following tools:
  Automake 1.16.2

Noteworthy changes and bug fixes since the previous beta (2.69b):

* A performance regression in AC_PROG_CXX has been corrected.
  See https://savannah.gnu.org/support/index.php?110285 for details.

* AC_PROG_YACC has been reverted to using ‘bison -y’.  After 2.70,
  we will instead add an AC_PROG_BISON macro for programs that
  require Bison extensions.
  See https://savannah.gnu.org/support/index.php?110266 for details.

* AC_PROG_LEX no longer looks for a library providing the function
  ‘yywrap’.  LEXLIB will only be set to ‘-lfl’ or ‘-ll’ if a
  scanner that defines both ‘main’ and ‘yywrap’ itself still needs
  something else from that library.

  Packages should define yywrap themselves, or use %noyywrap.

* When ‘$CC -E’ doesn’t run the C preprocessor, AC_PROG_CPP now looks
  in $PATH for ‘cpp’ before falling back to ‘/lib/cpp’.

* AC_TYPE_PID_T now gives pid_t the correct definition on 64-bit
  native Microsoft Windows.

* AC_INIT now trims extra white space from its arguments.  For instance,

AC_INIT([  GNU  Hello  ], [1.0])

  will set PACKAGE_NAME to “GNU Hello”.

* autoreconf will now run gtkdocize and intltoolize when appropriate.

* autoreconf now avoids complaints from subsidiary tools about
  unknown warning categories.  For example, ‘autoreconf -Wcross’
  will no longer cause complaints from (current released versions of)
  aclocal and automake.

* Generated configure scripts no longer fail catastrophically when
  stdin, stdout, or stderr is closed on startup.

* Many bugs related to building Autoconf itself have been corrected.
  These mostly affected non-GNU operating systems and situations where
  optional tools are not available.

* The obsolete macros AC_DIAGNOSE, AC_FATAL, AC_WARNING, and
  _AC_COMPUTE_INT are now replaced with modern equivalents by
  autoupdate.

* The macro AC_OBSOLETE is obsolete.  Autoupdate will replace it with
  m4_warn([obsolete], [explanation]).  If possible, macros using
  AC_OBSOLETE should be converted to use AU_DEFUN or AU_ALIAS instead,
  which enables autoupdate to replace them, but this has to be done by
  hand and is not always possible.

* AC_FC_LINE_LENGTH now documents the maximum portable length of
  "unlimited" Fortran source code lines to be 250 columns, not 254.

* Warnings about obsolete constructs are now on by default.
  They can be turned off with '-Wno-obsolete'.

* autoconf will now issue warnings (in the ‘syntax’ category) if the
  input file is missing a call to AC_INIT and/or AC_OUTPUT.

* AC_INIT will now issue warnings (in the “syntax” category) for a
  non-literal URL argument, and for a TARNAME argument which is either
  non-literal or contains characters that should not be used in file
  names (e.g. ‘*’).

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEgvhU885zF0uLYxdAkfzDK2dpqmQFAl9s1SgACgkQkfzDK2dp
qmSVvQ//WQ6YXjukhcBYwp6i7TsXaTfVt9eJIA6/cgReCwxYf8xaj6EfzSqU9zYd
TznyFgDpe+CewNcUr0WrBYst9vAjNa6ORD/cQM/CNGzIwpvLzOiRB8LfNyTPfTrp
fojXfkyBP94KRfT7bPIOm2EWhHMGa8Xw9GjUwzQofudWp3frnGQMoYr4ppfM75GA
l93E9MObJzR2iUyMZWUO9DPhiZxhhFnGKnPAT0mQ4MCoquAvlgAheVtdcMPE4iRL
IFbPdrDdCaGop3BTYdYlKyhoizzs2HjTMOOeYcbu/feHarqAjKADhB9x9DLDZeuN