assume GNU gettext >= 0.17

[Bruno Haible]

gnulib-tool emits a couple of notices that start with
"If you are using GNU gettext version 0.16.1 or older ..."

GNU gettext 0.17 was released in 2007, and according to
 all distros
(even CentOS 6) ship this version at least. So, by now we can
assume that everyone is using version 0.17 at least.

The user does not need to set XGETTEXT_OPTIONS for things that
AM_XGETTEXT_OPTION arranges for, automatically.


2021-07-25  Bruno Haible  

Assume GNU gettext >= 0.17.
* modules/vasprintf (Notice): Remove.
* modules/xvasprintf (Notice): Remove.
* modules/xprintf (Notice): Remove.
* modules/error (Notice): Remove.
* modules/verror (Notice): Remove.
* modules/argp (Notice): Remove.
* modules/propername (Notice): Remove.
* lib/propername.h: Remove outdated comment.

diff --git a/lib/propername.h b/lib/propername.h
index 8037de7..ee09d7c 100644
--- a/lib/propername.h
+++ b/lib/propername.h
@@ -51,7 +51,7 @@
output will look like this:
()
 
-   To use the 'propername' module requires three simple steps:
+   To use the 'propername' module requires two simple steps:
 
  1) Add it to the list of gnulib modules to import,
 
@@ -68,16 +68,6 @@
 
 (Optionally, here you can also add / * TRANSLATORS: ... * / comments
 explaining how the name is written or pronounced.)
-
- 3) If you are using GNU gettext version 0.16.1 or older, in po/Makevars,
-in the definition of the XGETTEXT_OPTIONS variable, add:
-
-   --keyword='proper_name:1,"This is a proper name. See the gettext 
manual, section Names."'
-   --keyword='proper_name_utf8:1,"This is a proper name. See the 
gettext manual, section Names."'
-
-This specifies automatic comments for the translator. (Requires
-xgettext >= 0.15. The double-quotes inside the quoted string are on
-purpose: they are part of the --keyword argument syntax.)
  */
 
 #ifndef _PROPERNAME_H
diff --git a/modules/argp b/modules/argp
index 38a7905..85eefe2 100644
--- a/modules/argp
+++ b/modules/argp
@@ -1,11 +1,6 @@
 Description:
 Hierarchical processing of command line arguments.
 
-Notice:
-If you are using GNU gettext version 0.16.1 or older, add the following options
-to XGETTEXT_OPTIONS in your po/Makevars:
-  --flag=argp_error:2:c-format --flag=argp_failure:4:c-format
-
 Files:
 lib/argp.h
 lib/argp-ba.c
diff --git a/modules/error b/modules/error
index a0fb4c0..2945c48 100644
--- a/modules/error
+++ b/modules/error
@@ -1,11 +1,6 @@
 Description:
 error and error_at_line functions: Error reporting.
 
-Notice:
-If you are using GNU gettext version 0.16.1 or older, add the following options
-to XGETTEXT_OPTIONS in your po/Makevars:
-  --flag=error:3:c-format --flag=error_at_line:5:c-format
-
 Files:
 lib/error.h
 lib/error.c
diff --git a/modules/propername b/modules/propername
index ab06a46..fb1e78a 100644
--- a/modules/propername
+++ b/modules/propername
@@ -1,12 +1,6 @@
 Description:
 Localization of proper names.
 
-Notice:
-If you are using GNU gettext version 0.16.1 or older, add the following options
-to XGETTEXT_OPTIONS in your po/Makevars:
-  --keyword='proper_name:1,"This is a proper name. See the gettext manual, 
section Names."'
-  --keyword='proper_name_utf8:1,"This is a proper name. See the gettext 
manual, section Names."'
-
 Files:
 lib/propername.h
 lib/propername.c
diff --git a/modules/vasprintf b/modules/vasprintf
index 59e5a86..91d082b 100644
--- a/modules/vasprintf
+++ b/modules/vasprintf
@@ -1,11 +1,6 @@
 Description:
 vsprintf with automatic memory allocation.
 
-Notice:
-If you are using GNU gettext version 0.16.1 or older, add the following options
-to XGETTEXT_OPTIONS in your po/Makevars:
-  --flag=asprintf:2:c-format --flag=vasprintf:2:c-format
-
 Files:
 lib/vasprintf.c
 lib/asprintf.c
diff --git a/modules/verror b/modules/verror
index e183f68..16ad0c5 100644
--- a/modules/verror
+++ b/modules/verror
@@ -1,11 +1,6 @@
 Description:
 verror and verror_at_line functions: Error reporting with va_list.
 
-Notice:
-If you are using GNU gettext version 0.16.1 or older, add the following options
-to XGETTEXT_OPTIONS in your po/Makevars:
-  --flag=verror:3:c-format --flag=verror_at_line:5:c-format
-
 Files:
 lib/verror.h
 lib/verror.c
diff --git a/modules/xprintf b/modules/xprintf
index de61260..f4942ce 100644
--- a/modules/xprintf
+++ b/modules/xprintf
@@ -1,12 +1,6 @@
 Description:
 a wrapper around printf that calls error upon ENOMEM or EILSEQ errors
 
-Notice:
-If you are using GNU gettext version 0.16.1 or older, add the following options
-to XGETTEXT_OPTIONS in your po/Makevars:
-  --flag=xprintf:1:c-format --flag=xvprintf:1:c-format
-  --flag=xfprintf:2:c-format --flag=xvfprintf:2:c-format
-
 Files:
 lib/xprintf.h
 lib/xprintf.c
diff --git a/modules/xvasprintf b/modules/xvasprintf
index 373c1fa..ae23314 100644
--- a/modules/xvasprintf
+++ b/modules/xvasprintf
@@ -1,10 +1,6 @@

Re: libunistring version detection w/ "configure -C"

[Bruno Haible]

Thien-Thi Nguyen wrote on 2021-01-26:
> At , there is a patch
> to libunistring version detection w/ "configure -C".  Does that
> look right?  It seems strange to me.

I can not reproduce the problem: Configuring gnunet-0.14.1 with
  ./configure -C --with-libunistring-prefix=/gnu-inst-libunistring/0.9.10
twice in a row produces the same config.cache in each run, and the
second run succeeds just like the first one.

The patch is also nonsense because it introduces invalid shell
syntax in the configure script: It replaces the valid code

  if test ${gl_cv_libunistring_version+y}
  then :

with

  if { as_var=gl_cv_libunistring_version, gl_libunistring_hexversion; eval test 
\${$as_var+y}; }
  then :

I hope the author of that patch is not from the University of Minnesota...

Bruno

Re: bug#33847: 27.0.50; emacsclient does not find server socket

[Paul Eggert]

On 7/24/21 11:32 PM, Eli Zaretskii wrote:


No modules are affected by the --disable-year2038 option on MS-Windows.


It turns out that I was wrong about that. (I don't normally look at the 
MS-Windows part of Gnulib and misunderstood some of the code I was 
reading.) Please see gnulib/m4/year2038.m4 for details. This file is in 
the patches I sent, or you can see it directly here:


https://git.savannah.gnu.org/cgit/gnulib.git/tree/m4/year2038.m4

This code knows about MS-Windows, Mingw, _USE_32BIT_TIME_T, 
__MINGW_USE_VC2005_COMPAT, and so forth, and attempts to do the right 
thing. As near as I can make out it should work for the scenario you 
describe, but I don't use MS-Windows so I could well be wrong. If I'm 
wrong and this code doesn't do what you want, I suggest contacting 
bug-gnulib to alert Bruno Haible, who wrote that part of the code. I'll 
cc bug-gnulib so that Bruno sees this email. (Bruno, this discussion is 
at .)


Here's some more background. There are two Gnulib modules involved.

The largefile module ensures that a program can open/stat/etc. all 
files, by widening types like off_t, dev_t and time_t if necessary. If 
it finds that time_t is narrower than what the system can support, it 
attempts to widen time_t; if this attempt fails it issues a warning but 
continues.


The year2038 module is stricter: it insists that time_t be at least 64 
bits and aborts 'configure' otherwise. (Strictly speaking, it should 
insist only on at least 33 bits (or 32 bits unsigned); I suppose I 
should look into fixing that.)


The Emacs patches that I sent do not use the year2038 module, because I 
expected that you wouldn't want to worry about the year 2038. The 
year2038 module is used by GNU packages like coreutils where Y2038 is a 
problem even now, due to the long lead times and lack of updatability on 
systems that use these other GNU packages.



So therefore my question seems to be even more important than I
thought, and I'm still asking which Gnulib modules are affected by
this, because I'd need to audit them carefully to see whether the
32-bit MS-Windows build with mingw.org's MinGW could be affected.


There should be no need to audit, because Gnulib still supports 
platforms that have only 32-bit time_t.


Gnulib is agnostic about time_t width, and is supposed to work even if 
time_t is 40 bits (which it is on a very few mainframes) or any other 
width. We regularly test it only on 32- and 64-bit time_t, though.

Re: bug#33847: 27.0.50; emacsclient does not find server socket

[Eli Zaretskii]

> Cc: la...@gnus.org, te...@gmx.com, 33...@debbugs.gnu.org, u...@gentoo.org,
>  Gnulib bugs 
> From: Paul Eggert 
> Date: Sun, 25 Jul 2021 09:22:06 -0700
> 
> On 7/24/21 11:32 PM, Eli Zaretskii wrote:
> 
> >> No modules are affected by the --disable-year2038 option on MS-Windows.
> 
> It turns out that I was wrong about that. (I don't normally look at the 
> MS-Windows part of Gnulib and misunderstood some of the code I was 
> reading.) Please see gnulib/m4/year2038.m4 for details. This file is in 
> the patches I sent, or you can see it directly here:
> 
> https://git.savannah.gnu.org/cgit/gnulib.git/tree/m4/year2038.m4
> 
> This code knows about MS-Windows, Mingw, _USE_32BIT_TIME_T, 
> __MINGW_USE_VC2005_COMPAT, and so forth, and attempts to do the right 
> thing. As near as I can make out it should work for the scenario you 
> describe, but I don't use MS-Windows so I could well be wrong. If I'm 
> wrong and this code doesn't do what you want, I suggest contacting 
> bug-gnulib to alert Bruno Haible, who wrote that part of the code. I'll 
> cc bug-gnulib so that Bruno sees this email. (Bruno, this discussion is 
> at .)

Thanks, I will take a look, although I now understand it isn't urgent,
since Emacs doesn't (yet) use the year2038 module.

> > So therefore my question seems to be even more important than I
> > thought, and I'm still asking which Gnulib modules are affected by
> > this, because I'd need to audit them carefully to see whether the
> > 32-bit MS-Windows build with mingw.org's MinGW could be affected.
> 
> There should be no need to audit, because Gnulib still supports 
> platforms that have only 32-bit time_t.
> 
> Gnulib is agnostic about time_t width, and is supposed to work even if 
> time_t is 40 bits (which it is on a very few mainframes) or any other 
> width. We regularly test it only on 32- and 64-bit time_t, though.

Thanks, that's good to know.