gperf dependency not documented

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

Re: c32width gives incorrect return values in C locale

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

Re: obstack module has alignment issues on sparc? (Re: set_labels_identifiers_target -fsanitize=undefined error)

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

Re: c32width gives incorrect return values in C locale

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

Re: c32width gives incorrect return values in C locale

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

Re: Take account of splitting option in gendocs.sh

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 comments. I have

Re: Take account of splitting option in gendocs.sh

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 Gavin Smi

Re: Take account of splitting option in gendocs.sh

ex 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 by node. + * buil

Re: Take account of splitting option in gendocs.sh

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 patch? This

Re: Take account of splitting option in gendocs.sh

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

Take account of splitting option in gendocs.sh

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-level

Re: -Wlto-type-mismatch warning in error()

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

Re: -Wlto-type-mismatch warning in error()

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

Re: -Wlto-type-mismatch warning in error()

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, > ...) > | ^ >

Re: Avoid gnulib redefinitions - MDA

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 d

Re: Avoid gnulib redefinitions - MDA

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 >

Re: Avoid gnulib redefinitions - MDA, free-posix

ake 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): + Add -DGNULIB_INTERNAL to A

Avoid gnulib redefinitions - MDA, free-posix

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

Re: conditional "LIBUNISTRING_COMPILE_UNIWIDTH_WIDTH" was never defined.

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

Fwd: bug#50116: Text on GNU grep webpage far too big

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: >

__nonnull on DragonFlyBSD 5.9

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

Re: How to avoid fdopen redefinition?

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

How to avoid fdopen redefinition?

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

Results from running autoupdate on gnulib m4 files

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

Re: autoconf-2.69c released [beta]

> 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

Re: autoconf-2.69c released [beta]

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

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/ChangeLo

Re: Variant wcwidth results on Solaris

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

Re: Variant wcwidth results on Solaris

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

Variant wcwidth results on Solaris

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

Re: gt_INTL_MACOSX not defined by gettext.m4

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

gt_INTL_MACOSX not defined by gettext.m4

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

Re: Gnulib's wctype.h fails to compile with MinGW

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

Re: regex.c value out of range on Solaris compiler

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

Re: regex.c value out of range on Solaris compiler

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

Re: regex.c value out of range on Solaris compiler

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

regex.c value out of range on Solaris compiler

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

Re: Remove dependency of getdelim on realloc-posix

On 13 August 2016 at 15:08, Andreas Schwab <sch...@linux-m68k.org> wrote: > On Aug 13 2016, Gavin Smith <gavinsmith0...@gmail.com> wrote: > >> +2016-08-13 Gavin Smith <gavinsmith0...@gmail.com> >> + >> + * modules/getdelim: Remove dependency on

Remove dependency of getdelim on realloc-posix

..9033e14 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2016-08-13 Gavin Smith <gavinsmith0...@gmail.com> + + * modules/getdelim: Remove dependency on realloc-posix. + * lib/getdelim.c (getdelim): Set errno to ENOENT if realloc failed, + as is done in lib/canoni

Re: texinfo.tex 2016-05-07.20: "Tex capacity exceeded" with Emacs manuals

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 >

Re: texinfo.tex 2016-05-07.20: "Tex capacity exceeded" with Emacs manuals

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

Re: nl_langinfo.m4: HAVE_LANGINFO_CODESET unquoted

On 12 January 2016 at 00:53, Gavin Smith <gavinsmith0...@gmail.com> 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 exec

Re: nl_langinfo.m4: HAVE_LANGINFO_CODESET unquoted

On 12 January 2016 at 12:28, Gavin Smith <gavinsmith0...@gmail.com> 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; the

regex error with NetBSD pcc

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.

Re: nl_langinfo.m4: HAVE_LANGINFO_CODESET unquoted

On 11 January 2016 at 23:08, Paul Eggert <egg...@cs.ucla.edu> 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

nl_langinfo.m4: HAVE_LANGINFO_CODESET unquoted

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

Re: How to find out which modules have brought in a particular module

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

Re: How to find out which modules have brought in a particular module

> 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

AC_SUBST of pkglibexecdir in 'configmake' module

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

Re: configure script does not give error if ar is not found

On 23 June 2015 at 20:37, Tim Rice t...@multitalents.net 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

configure script does not give error if ar is not found

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

Re: Compilation warnings on MinGW due to Gnulib's wcwidth

On 19 June 2015 at 13:36, Eli Zaretskii e...@gnu.org wrote: Date: Fri, 19 Jun 2015 13:12:00 +0100 From: Gavin Smith gavinsmith0...@gmail.com Cc: bug-gnulib@gnu.org, texinfo-de...@gnu.org On 19 June 2015 at 07:48, Eli Zaretskii e...@gnu.org wrote: There was no wcwidth.h in texinfo-5.9.93's

Re: Compilation warnings on MinGW due to Gnulib's wcwidth

On 19 June 2015 at 13:36, Eli Zaretskii e...@gnu.org wrote: Date: Fri, 19 Jun 2015 13:12:00 +0100 From: Gavin Smith gavinsmith0...@gmail.com Cc: bug-gnulib@gnu.org, texinfo-de...@gnu.org On 19 June 2015 at 07:48, Eli Zaretskii e...@gnu.org wrote: There was no wcwidth.h in texinfo-5.9.93's

Re: Compilation warnings on MinGW due to Gnulib's wcwidth

On 19 June 2015 at 07:48, Eli Zaretskii e...@gnu.org 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/),

Re: Compilation warnings on MinGW due to Gnulib's wcwidth

On 19 June 2015 at 13:12, Gavin Smith gavinsmith0...@gmail.com wrote: On 19 June 2015 at 07:48, Eli Zaretskii e...@gnu.org 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

Re: Compilation warnings on MinGW due to Gnulib's wcwidth

On 18 June 2015 at 16:26, Eli Zaretskii e...@gnu.org 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

Call to locale_charset within wcwidth

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

getpt support?

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

Re: getpt support?

On Mon, Jun 2, 2014 at 4:47 PM, Paul Eggert egg...@cs.ucla.edu 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