I was reading a man page for gettext(3) and I wanted to know where
the page came from. I scrolled to the bottom of the page and there was:
GNU gettext 0.22.5 May 2001 GETTEXT(3)
I downloaded gettext-0.23 and checked that the string "May 2001" is also
prese
> You are right. And still, the problem with the nonexistent/empty POT file
> is only the smallest problem in the current state of gnulib localizations.
>
> The current state is a failure. Documentation was added on 2008-01-03 [1][2],
> but nevertheless
>
> * Among the > 100 packages that use g
On Sat, Dec 07, 2024 at 08:59:56AM +0100, Bruno Haible wrote:
> > This is likely to happen for other project too if they do not use
> > many Gnulib modules or remove modules.
> >
> > The effect of this means that the package will be distributed with the
> > Gnulib translation catalogs with extra t
xt:
diff --git a/ChangeLog b/ChangeLog
index c70df89b2f..11ab674fae 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,14 @@
+2023-12-06 Gavin Smith
+
+ gnulib-tool: use xgettext --force-po
+ * pygnulib/GLEmiter.py (po_Makevars): Put --force-po in
+ XGETTEXT_OPTIONS.
+
can confirm this works. Thanks for the fix!
> 2024-11-12 Bruno Haible
>
> gnulib-tool.py: Fix logic of --remove-import option.
> Reported by Gavin Smith in
> <https://lists.gnu.org/archive/html/bug-gnulib/2024-11/msg00101.html>.
> * pygnulib/
In the Texinfo project, I wanted to try to remove a gnulib module. The
command I ran was:
../../../../gnulib/gnulib-tool --remove-import copy-file
This is inside a deeply nested directory in the project source code.
However, this has the opposite effect to that intended:
diff --git a/tp/Texinf
The DEPENDENCIES file in gnulib states a module that depends on the gperf
program:
* GNU gperf 3.0.1 or newer.
+ 3.0.1 or newer is mandatory, but 3.1 or newer is recommended.
Needed if you use the 'iconv_open' module.
However, it is not the only module that uses this program. gperf is
also
On Wed, Nov 15, 2023 at 09:42:21AM +0100, Patrice Dumas wrote:
> On Wed, Nov 15, 2023 at 12:22:24AM -0800, Paul Eggert wrote:
> > On 2023-11-13 01:28, Patrice Dumas wrote:
> > > According to your mail
> > > https://lists.gnu.org/archive/html/bug-libunistring/2023-11/msg0.html
> > >
> > > char3
On Tue, Nov 14, 2023 at 10:16:33PM +0100, Bruno Haible wrote:
> Sam James wrote:
> > > It appears that the obstack gnulib module is the culprit.
>
> I replied:
> > Therefore, if it is a bug in gnulib, it is also a bug in glibc.
>
> Sam was right. I was wrong. It is a bug in the 'obstack' gnulib m
On Sat, Nov 11, 2023 at 11:54:52PM +0100, Bruno Haible wrote:
> [CCing bug-libunistring]
> Gavin Smith wrote:
> > I did not understand why uc_width was said to be "locale dependent":
> >
> > "These functions are locale dependent."
> >
> >
On Sat, Nov 11, 2023 at 09:06:41PM +0100, Bruno Haible wrote:
> [CCing bug-gnulib]
> Indeed, the c32* functions by design work only on those Unicode characters
> that can be represented as multibyte sequences in the current locale.
>
> I'll document this better in the Gnulib manual.
>
> Since you
On Wed, Jul 12, 2023 at 04:02:34PM +0200, Bruno Haible wrote:
> Gavin Smith wrote:
> > I've made minor changes to the patch as specified in Karl's response below.
> > Please can this be applied?
>
> Thanks for having taken into account both my and Karl's c
this be applied?
The Texinfo package is still using a custom gendocs template for some of
its manuals and I would like to get rid of it to simplify our build process.
diff --git a/ChangeLog b/ChangeLog
index e55bfec8ed..9c8804f3f6 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,14 @@
+2023-07-12
ChangeLog b/ChangeLog
index a0de338759..41a27c6710 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2023-03-26 Gavin Smith
+
+ gendocs: support chapter- and section-level split
+ * doc/gendocs_template: Add lines to mark parts of file to output
+ only when splitting HTML b
On Mon, Feb 27, 2023 at 07:30:37AM +, Gavin Smith wrote:
> OK it doesn't do any harm to keep the texi2html support in.
>
> The patch I sent applied for both texi2html and texi2any, although I
> hadn't tested it with texi2html.
Is there any progress on applying this pa
On Sun, Feb 26, 2023 at 09:52:08PM +0100, Bruno Haible wrote:
> Gavin Smith wrote:
> > I notice that this script also still supports texi2html, which is no
> > longer developed. I could produce a patch to remove this support if
> > it was very likely that nobody was rely
d. I could produce a patch to remove this support if
it was very likely that nobody was relying on it.
diff --git a/ChangeLog b/ChangeLog
index 9477335e75..d67b9b2f0a 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2023-02-26 Gavin Smith
+
+ gendocs: support chapter- and section-
On Sat, Dec 10, 2022 at 01:48:23AM +, Gavin Smith wrote:
> Making the symbols provided by install-info.c weak might work,
> so one idea is that when a program uses Gnulib, all of the global
> symbols from the program (excluding Gnulib) should be marked as weak
> in produced obje
On Thu, Dec 08, 2022 at 09:25:01AM +0100, Arsen Arsenović wrote:
> > Shouldn't we report this to the GCC folks? It could be a bug in lto,
> > no? I mean, 'error' is not a symbol that applications cannot use, and
> > if an application defines a function by that name, it should not be
> > imported
On Wed, Dec 07, 2022 at 08:57:45PM +, Sam James wrote:
> ../gnulib/lib/error.h:33:13: error: type of ‘error’ does not match original
> declaration [-Werror=lto-type-mismatch]
>33 | extern void error (int __status, int __errnum, const char *__format,
> ...)
> | ^
> insta
On Sun, Oct 30, 2022 at 12:09:50AM +0200, Bruno Haible wrote:
> Gavin Smith wrote:
> > so it sounds like we are better off using #undef before
> > including the Perl headers to avoid depending on undocumented
> > functionalities. Thanks.
>
> Using #undef means to decl
On Sat, Oct 29, 2022 at 11:48:41PM +0200, Bruno Haible wrote:
> > Should we use the variables with the GL_ prefix now and is this something
> > we can rely on? Or should we simply #undef fdopen and the other symbols?
>
> The way to avoid a particular MDA symbol definition (GNULIB_MDA_FDOPEN=0
> b
e are changes to
make to the patch.
diff --git a/ChangeLog b/ChangeLog
index 6f4bea5c1c..994f457e70 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,21 @@
+2020-10-29 Gavin Smith
+
+ Avoid unrequested 'free' redefinition
+
+ * gnulib-tool (func_emit_lib_Makefile_am):
+
Previously in the Texinfo project, we added variables to configure.ac to
stop the redefinition of "Microsoft deprecated aliases":
https://lists.gnu.org/archive/html/bug-gnulib/2021-03/msg4.html
For example, GNULIB_MDA_FDOPEN to stop the redefinition of 'fdopen'.
Recently, it was reported tha
>
> Avoid error "conditional LIBUNISTRING_COMPILE_... was never defined"
> when option --conditional-dependencies is used (regression 2022-01-09).
> Reported by Gavin Smith in
> <https://lists.gnu.org/archive/html/bug-gnulib/2022-01/msg
just the section heading).
-- Forwarded message -
From: Steve Ward
Date: Thu, Aug 19, 2021 at 12:56 PM
Subject: Re: bug#50116: Text on GNU grep webpage far too big
To: Gavin Smith
Cc: <50...@debbugs.gnu.org>
On Thu, Aug 19, 2021 at 2:12 AM Gavin Smith wrote:
>
I'm hoping for some help tracking down an error trying to compile Texinfo
on DragonFlyBSD 5.9. The error message is as follows:
depbase=`echo basename-lgpl.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`; gcc
-DHAVE_CONFIG_H -I. -I../.. -g -O2 -MT basename-lgpl.o -MD -MP -MF
$depbase.Tpo -c -o basen
On Mon, Mar 1, 2021 at 4:46 PM Bruno Haible wrote:
> > Is there any way of turning this off?
>
> Yes: In your configure.ac, after the invocation of gl_INIT, add an assignment
>
> GNULIB_MDA_FDOPEN=0
>
> > https://lists.gnu.org/archive/html/bug-gnulib/2020-12/msg00220.html
> >
> > It says in that
When using a stdin.h from gnulib with Perl's extension headers (e.g.
XSUB.h), under MinGW there can be compiler warnings due to
redefinition of an fdopen symbol. This was reported here (point 1):
https://lists.gnu.org/archive/html/bug-texinfo/2021-02/msg00152.html
We don't use fdopen in the progr
Because of the upcoming autoconf 2.70 release gives more warnings, I
checked the other files in gnulib in the m4 directory with
autoupdate -v *.m4 2>&1 | tee log
Fortunately, there are not too many issues (on top of the other issues I
already reported). Here are the relevant excerpts from the
> 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/lib
> -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.
%
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
On Sat, Mar 30, 2019 at 12:33:32PM +0100, Bruno Haible wrote:
> > It appears that lib/wcwidth.c does actually use uc_width. So the best
> > solution might be to carry on using the wcwidth function in the source
> > code for texi2any (instead of changing this to uc_width), and change the
> > con
Thank you for your detailed response.
> Different systems have different terminal emulators, and accordingly
> also different wcwidth functions.
Without knowing anything about the terminal emulators in question, it
seems to me likely that there would be several terminal emulators with
differen
I wondered if there has been any change since this report:
https://lists.gnu.org/archive/html/bug-gnulib/2008-08/msg00209.html
The issue is that on Solaris 10 and Solaris 11, wcwidth returns 2
instead of 1 for some characters, for example, opening double quote “.
Some of these characters are li
On Fri, Jul 14, 2017 at 12:57:43AM +0200, Bruno Haible wrote:
> Gavin Smith wrote:
> > Originally reported here:
> > http://lists.gnu.org/archive/html/bug-texinfo/2017-07/msg00026.html
>
> Looking at the gnulib-cache.m4 and gnulib-comp.m4 from said package:
> * gette
gettext.m4 from gnulib uses a macro gt_INTL_MACOSX, but running
gnulib-tool --add-import doesn't cause this macro to be defined in the
produced configure script.
There is a definition in intlmacosx.m4 but this file is not pulled in.
I have a backup of this file intlmacosx.m4~ which was probably cr
On Sun, Apr 23, 2017 at 08:20:20PM -0400, Assaf Gordon wrote:
> ---
>
> On Solaris 5.10, compilation fails due to a conflict in gnulib's getopt
> module.
> See full build log here:
> https://pretest.housegordon.org/g/4602/logs/make.log?inlined=1
> (search for "getopt_int" to find the error).
>
On Thu, Apr 27, 2017 at 08:50:25PM +0300, Eli Zaretskii wrote:
> > From: Bruno Haible
> > Date: Thu, 27 Apr 2017 19:03:35 +0200
> >
> > Thanks for the report and suggested fix.
> >
> > The #ifdefology here seems a bit fragile to me (will likely break in other
> > forks of mingw), therefore I'm u
On Sat, Apr 15, 2017 at 02:40:49PM -0700, Paul Eggert wrote:
> Sorry, I don't understand how this could be. regex_internal.h's "#define
> gettext(msgid) msgid" line is in the else-part of the #if that #includes
> libintl.h in its then-part, so how can libintl.h's #define for gettext be
> active whe
On Fri, Apr 14, 2017 at 07:00:06PM -0700, Paul Eggert wrote:
> On 04/14/2017 02:27 PM, Gavin Smith wrote:
> > /opt/solarisstudio12.3/bin/c99 -Xc -D_XPG6 -DHAVE_CONFIG_H -I. -I../..
> > -D_REENTRANT -I/opt/csw/include -c -o regex.o regex.c
> > "regex_internal.h", lin
On Fri, Apr 14, 2017 at 10:27:45PM +0100, Gavin Smith wrote:
> Line 21273 is
> subl$4294967296,%eax
>
> Line 21294 is
> subl$4294967296,%eax
>
>
> the problem occurs. I believe that the faulty code is coming from the
> use of INT_ADD_WRAPV
Hello,
When I try to compile a program using the 'regex' module on Solaris 10,
I get the output
/opt/solarisstudio12.3/bin/c99 -Xc -D_XPG6 -DHAVE_CONFIG_H -I. -I../..
-D_REENTRANT -I/opt/csw/include -c -o regex.o regex.c
"regex_internal.h", line 105: warning: macro redefined: gettext
"regex_
On 13 August 2016 at 15:08, Andreas Schwab wrote:
> On Aug 13 2016, Gavin Smith wrote:
>
>> +2016-08-13 Gavin Smith
>> +
>> + * modules/getdelim: Remove dependency on realloc-posix.
>> + * lib/getdelim.c (getdelim): Set errno to ENOENT if reall
14e8e..9033e14 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2016-08-13 Gavin Smith
+
+ * modules/getdelim: Remove dependency on realloc-posix.
+ * lib/getdelim.c (getdelim): Set errno to ENOENT if realloc failed,
+ as is done in lib/canonicalize-lgpl.c (__realpath).
+
20
On 26 May 2016 at 16:48, Paul Eggert wrote:
> OK, here's a smaller example taken from the Emacs source code. Unpack the
> attached tarball in a fresh directory, copy the latest Gnulib texinfo.tex
> into it, and run the shell command 'texi2pdf bovine.texi'. On my platform
> (Fedora 23 x86-64, texi2
On 25 May 2016 at 19:08, Paul Eggert wrote:
> texinfo.tex version 2016-05-07.20 (the current version in Gnulib) causes
> what appears to be runaway recursion when used to make PDF files for GNU
> Emacs. The Emacs bug report is here:
>
> http://bugs.gnu.org/23611
>
> To reproduce the problem on a F
Using the "regex" module, I had the error
#error "Add case for new bitset_word_t size"
from regex_internal.h when using pcc under NetBSD.
$ pcc --version
pcc 1.2.0.DEVEL 20141228 for x86_64--netbsd
The problem appears to be that the C preprocessor thinks that
ULONG_MAX is a negative value. Wit
On 12 January 2016 at 12:28, Gavin Smith wrote:
> func_gl_gnulib_m4code_nl_langinfo ()
> {
> if ! $gl_gnulib_enabled_nl_langinfo; then
> gl_FUNC_NL_LANGINFO
> if test $HAVE_NL_LANGINFO = 0 || test $REPLACE_NL_LANGINFO = 1; then
> AC_LIBOBJ([nl_lan
On 12 January 2016 at 00:53, Gavin Smith wrote:
> Maybe AC_REQUIRE isn't hoisting the code far enough? The code is
> remaining in the function corresponding to a gnulib module's code, and
> not going to the very top level. The code is expanded, but is executed
> too la
On 11 January 2016 at 23:08, Paul Eggert wrote:
> On 01/11/2016 12:32 PM, Gavin Smith wrote:
>>
> Let's do the latter, since these variables should all be set to 0 or 1 by
> then.
>
> The macro in question AC_REQUIREs gl_LANGINFO_SET, which should set
&
In the nl_langinfo.m4 file, there's a test:
if test $HAVE_LANGINFO_CODESET = 1 && test $HAVE_LANGINFO_ERA = 1 \
&& test $FUNC_NL_LANGINFO_YESEXPR_WORKS = 1; then
:
else
This gave an (apparently harmless) error message when configuring
under OpenIndiana 11:
./configure[22339]:
> Here's basic functionality that shows direct dependencies
Also sending as an attachment in case the diff was mangled in the email.
diff
Description: Binary data
On 21 October 2015 at 02:42, Pádraig Brady wrote:
> There was some work on displaying a graph previously.
> http://lists.gnu.org/archive/html/bug-gnulib/2011-03/msg00276.html
> Something like this is worth adding I think.
>
> cheers,
> Pádraig
Here's basic functionality that shows direct dependen
Hello,
The configmake module uses AC_SUBST for pkglibexecdir, which overrides
Automake's default definition. If gl_CONFIGMAKE_PREP isn't run then
the substituted value is empty.
This was a problem with Texinfo, reported here:
http://lists.gnu.org/archive/html/bug-texinfo/2016-01/msg00046.html
Ma
I'm interested in reducing the number of checks done in a configure
script: one way could be to make more use of conditional dependencies
between modules. gnulib-tool --add-import lists the modules which were
used and which were brought in as dependencies. However, there are
some things I'd like to
On 23 June 2015 at 20:37, Tim Rice wrote:
>> I was trying to build Texinfo on a SunOS 5.10 sparc system, but got an
>> error message when it tried to build gnulib, that "ar" didn't exist.
>> Looking at config.log I have:
>
> Is /usr/ccs/bin in your PATH?
> What does "whereis ar" say?
>
It wasn't.
Hello,
I was trying to build Texinfo on a SunOS 5.10 sparc system, but got an
error message when it tried to build gnulib, that "ar" didn't exist.
Looking at config.log I have:
configure:5731: checking for egrep
configure:5793: result: /usr/xpg4/bin/grep -E
configure:5800: checking for Minix Amst
On 19 June 2015 at 13:36, Eli Zaretskii wrote:
>> Date: Fri, 19 Jun 2015 13:12:00 +0100
>> From: Gavin Smith
>> Cc: bug-gnulib@gnu.org, texinfo-de...@gnu.org
>>
>> On 19 June 2015 at 07:48, Eli Zaretskii wrote:
>> > There was no wcwidth.h in texinfo-5.9.
On 19 June 2015 at 13:36, Eli Zaretskii wrote:
>> Date: Fri, 19 Jun 2015 13:12:00 +0100
>> From: Gavin Smith
>> Cc: bug-gnulib@gnu.org, texinfo-de...@gnu.org
>>
>> On 19 June 2015 at 07:48, Eli Zaretskii wrote:
>> > There was no wcwidth.h in texinfo-5.9.
On 19 June 2015 at 13:12, Gavin Smith wrote:
> On 19 June 2015 at 07:48, Eli Zaretskii wrote:
>> There was no wcwidth.h in texinfo-5.9.93's gnulib; now there is. So
>> the arrangement of how that declaration is pulled in changed
>> significantly since then.
>
>
On 19 June 2015 at 07:48, Eli Zaretskii wrote:
> There was no wcwidth.h in texinfo-5.9.93's gnulib; now there is. So
> the arrangement of how that declaration is pulled in changed
> significantly since then.
I downloaded the texinfo-5.9.94 pretest
(http://alpha.gnu.org/gnu/texinfo/), and it does
On 18 June 2015 at 16:26, Eli Zaretskii wrote:
> Building the current Texinfo trunk tip with MinGW produces a barrage
> of compiler warnings like these:
>
> gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../..-Id:/usr/include -gdwarf-4
> -g3 -O2 -MT mbscasecmp.o -MD -MP -MF $depbase.Tpo -c -o mbscas
On Sun, Feb 1, 2015 at 10:07 AM, Daiki Ueno wrote:
> Eli Zaretskii writes:
>
>> Perhaps we could call _configthreadlocale to see if the value of
>> setlocale can be cached?
>
> Yes, but then we would need to hook setlocale to invalidate the cache,
> and currently the setlocale module is not liste
I am working on a program that uses wcwidth from gnulib on many
characters in a buffer, however this is reported to be slow under some
platforms.[1]
The reason appears to be the call to locale_charset within the wcwidth
implementation. I found some discussion of speeding this up in the
bug-gnulib
On Mon, Jun 2, 2014 at 4:47 PM, Paul Eggert wrote:
> Why not just use posix_openpt?
If the two functions are exactly the same (I think they are), this
would be acceptable. There are two weak reasons to use getpt instead:
(i) posix_openpt isn't documented in the glibc manual (but I've raised
a bug
I was wondering what the chances would be of getting support for the
getpt function in gnulib? It's a GNU stdlib.h extension to get a file
descriptor for a master pseudo-terminal. As far as I can tell it does
something very similar to posix_openpt, and there is already a gnulib
posix_openpt module.
68 matches
Mail list logo
