Re: libgcrypt.m4 gnulib/libgcrypt unsync

[Bruno Haible]

Werner (or Simon),

Karl Berry wrote:
> Looks like libgcrypt.m4 was modified in gnulib a couple days ago (from
> AC_HELP_STRING to AS_HELP_STRING), but in theory it's supposed to be
> synced with the libgcrypt repository. Help?

Karl is right. Can the following patch be applied upstream, please?


2020-09-27  Gavin Smith  

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

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, 2011, 2014, 2018, 2020 g10 Code GmbH
 #
 # 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 +9,7 @@
 # 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
+# Last-changed: 2020-09-27
 
 
 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

libgcrypt.m4 gnulib/libgcrypt unsync

[Karl Berry]

Looks like libgcrypt.m4 was modified in gnulib a couple days ago (from
AC_HELP_STRING to AS_HELP_STRING), but in theory it's supposed to be
synced with the libgcrypt repository. Help?

--- libgcrypt/src/libgcrypt.m4  2020-03-31 09:57:48.0 -0700
+++ gnulib/m4/libgcrypt.m4  2020-09-28 00:24:10.741933569 -0700
@@ -1,3 +1,3 @@
 # libgcrypt.m4 - Autoconf macros to detect libgcrypt
-# Copyright (C) 2002, 2003, 2004, 2011, 2014, 2018 g10 Code GmbH
+# Copyright (C) 2002, 2003, 2004, 2011, 2014, 2018, 2020 g10 Code GmbH
 #
@@ -11,3 +11,3 @@
 #
-# Last-changed: 2018-11-13
+# Last-changed: 2020-09-27
 
@@ -32,3 +32,3 @@
   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)]),

Re: hard-locale.c: SETLOCALE_NULL_MAX

[Bruno Haible]

Hi Marc,

> The compiler throws the following error at me:
> 
> lib/hard-locale.c: In function 'hard_locale':
> lib/hard-locale.c:29:15: error: 'SETLOCALE_NULL_MAX' undeclared (first
> use in this function); did you mean 'SETLOCALE_NULL_ALL_MTSAFE'?
>29 |   char locale[SETLOCALE_NULL_MAX];
>   |   ^~

Does the error occur always, or only with "make -j"?

Are the following statements true in your build?
  (1) I use the module 'hard-locale'.
  (2) I use the module 'setlocale-null'.
  (3) config.status defines GNULIB_SETLOCALE_NULL to 1.
  (4) The file lib/setlocale_null.h exists.
  (5) The file lib/locale.h includes setlocale_null.h.
  (6) The -I options passed to GCC make sure that setlocale_null.h gets found.

Bruno

Re: hard-locale.c: SETLOCALE_NULL_MAX

[Marc Nieper-Wißkirchen]

PS It may also be due to a problem in my build system (I am using
non-recursive make) so that the system-wide locale.h is included and
not the Gnulib version...

Am Mi., 30. Sept. 2020 um 16:29 Uhr schrieb Marc Nieper-Wißkirchen
:
>
> It seems that I have stumbled across the same bug as reported here:
>
> https://bugs.gentoo.org/709732
>
> The compiler throws the following error at me:
>
> lib/hard-locale.c: In function 'hard_locale':
> lib/hard-locale.c:29:15: error: 'SETLOCALE_NULL_MAX' undeclared (first
> use in this function); did you mean 'SETLOCALE_NULL_ALL_MTSAFE'?
>29 |   char locale[SETLOCALE_NULL_MAX];
>   |   ^~
>   |   SETLOCALE_NULL_ALL_MTSAFE
> lib/hard-locale.c:29:15: note: each undeclared identifier is reported
> only once for each function it appears in
> lib/hard-locale.c:31:7: warning: implicit declaration of function
> 'setlocale_null_r' [-Wimplicit-function-declaration]
>31 |   if (setlocale_null_r (category, locale, sizeof (locale)))
>   |   ^~~~
>
> Is there a quick fix possible?
>
> Thanks,
>
> Marc

hard-locale.c: SETLOCALE_NULL_MAX

[Marc Nieper-Wißkirchen]

It seems that I have stumbled across the same bug as reported here:

https://bugs.gentoo.org/709732

The compiler throws the following error at me:

lib/hard-locale.c: In function 'hard_locale':
lib/hard-locale.c:29:15: error: 'SETLOCALE_NULL_MAX' undeclared (first
use in this function); did you mean 'SETLOCALE_NULL_ALL_MTSAFE'?
   29 |   char locale[SETLOCALE_NULL_MAX];
  |   ^~
  |   SETLOCALE_NULL_ALL_MTSAFE
lib/hard-locale.c:29:15: note: each undeclared identifier is reported
only once for each function it appears in
lib/hard-locale.c:31:7: warning: implicit declaration of function
'setlocale_null_r' [-Wimplicit-function-declaration]
   31 |   if (setlocale_null_r (category, locale, sizeof (locale)))
  |   ^~~~

Is there a quick fix possible?

Thanks,

Marc

Re: recursive algorithms and stack overflow

[Marc Nieper-Wißkirchen]

Am Mi., 26. Aug. 2020 um 12:13 Uhr schrieb Bruno Haible :

> [CCing bug-gnulib and Marc Nieper-Wißkirchen.]
>
> Paul Eggert wrote in :
> > Bug#42931 prompted me to change the way
> > that the Gnulib diffseq module recurses so that the stack size is O(log N)
> > rather than O(N). I installed this change into Gnulib, here:
> >
> > https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=7aadb23803a8fb71d07e6e87ffb1ca510d86f8ef
>
> Similarly, there was a bug report against libcroco [1] recently, because
> libcroco's CSS matching is recursive and can thus trigger stack overflow.
>
> It seems this is something to watch out, when we have recursive algorithms
> (which is quite frequent). Data sizes of 100 MB (or even just 100 KB) are
> considered "small" by today's computation means; if they can trigger stack
> overflow, users are unhappy.

I agree with all the points made. (And that's why a language with
proper tail calls like Scheme is so convenient.)

> Possible mitigations are:
>   - Use iteration instead of recursion when possible - like here in diffseq.h,
>   - Use iteration with a simulated heap-allocated stack - it would be useful
> to have the stack module in Gnulib for this (Marc?),

I am sorry for my silence. I haven't forgotten about this project. I
will submit a patch hopefully soon.

Marc

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