Re: @itemize @asis is not well supported

[Bruno Haible]

Gavin Smith wrote:
> it is not worth changing and making practically every use of
> @itemize in a Texinfo manual being flagged as incorrect, in my opinion.

I agree. Counting the number of existing usages in Debian [1][2]:
  - 8753 times '@itemize @bullet' without braces,
  - 288 times '@itemize @bullet{}' with braces.

Asking more than 340 packages to change their .texi files is not realistic.

Bruno

[1] 
https://codesearch.debian.net/search?q=%40itemize+%40bullet+-path%3Atexinfo.tex=1
[2] 
https://codesearch.debian.net/search?q=%40itemize+%40bullet%7B%7D+-path%3Atexinfo.tex=1

Re: @itemize @asis is not well supported

[Bruno Haible]

Patrice Dumas wrote:
> >   The command after @itemize should not require an argument, but @asis 
> > needs an argument. Try @asis{} instead.
> >   The command after @itemize should not require an argument, but @code 
> > needs an argument. Try @code{} instead.
> 
> What about
> 
>   @itemize command argument should not require an argument, but @asis does. 
> Use braces for @asis

This is good; I find it reasonably understandable.

Bruno

Re: @itemize @asis is not well supported

[Bruno Haible]

Andreas Schwab wrote:
> It's not a might, it's a don't do it.  It's a misuse of a command that
> requires an argument, in a place that doesn't pass one.

Thanks for the succint formulation. Can we use it in the warning?

  The command after @itemize should not require an argument, but @asis needs an 
argument. Try @asis{} instead.
  The command after @itemize should not require an argument, but @code needs an 
argument. Try @code{} instead.

Bruno

Re: @itemize @asis is not well supported

[Bruno Haible]

Patrice Dumas wrote:
> Ok, I propose as warning message :
> 
>  "non-mark brace command `\@%s' as \@%s argument should have braces"
> 
> leading to something like
> 
>  non-mark brace command `@asis' as @itemize argument should have braces

This is not easy to understand. How about

  @itemize argument @asis might not work in TeX mode; try using @asis{} instead
  @itemize argument @code might not work in TeX mode; try using @code{} instead

?

Bruno

Re: @itemize @asis is not well supported

[Bruno Haible]

Patrice Dumas wrote:
> @itemize @asis is definitely not the same as @table @asis.  Indeed,
> @table argument is applied to the @item argument, while @itemize
> argument precedes the @item argument.

Ah, thanks for explaining.

It also explains why
  @itemize @code
did not have the desired effect, whereas
  @table @code
is documented.

> It is already possible to use an
> empty @asis as @itemize argument, with braces, like
> 
> @itemize @asis{}
> 
> This seems to me to be a better use to advocate, in particular to avoid
> the idea that @itemize @asis could be similar to @table @asis.

Thanks, I'll use that, instead of @w{}.

> Regarding the lack of error by makeinfo, I would tend to consider that
> makeinfo is incorrect, I think that there should at least be a warning
> message ...

Yes, please. Since "make" only produces the info-formatted output by default,
without the warning, developers won't realize their mistake until the time
they run "make distcheck" (since "make distcheck" creates the dvi/ps/pdf
formatted documentation). It is better to get the developers' attention
already during "make".

Bruno

@itemize @asis is not well supported

[Bruno Haible]

@itemize @asis
seems to work in HTML and info mode only, not in TeX mode.


How to reproduce (with texinfo-7.1):

$ git clone git://git.savannah.gnu.org/gnulib.git
$ cd gnulib
$ git checkout f52d4a7b78be73060cf01640b40ebc88193c12e8
$ cd doc
$ make pdf
...
/tmp/gnulib/doc/gnulib-tool.texi:472: Argument of @asis has an extra }.
 
@par 
 
   }
@doitemize ...1}@setbox 0 = @hbox {@itemcontents }
  @ifx @itemcontents @empty ...
l.472 @itemize @asis

? 
/tmp/gnulib/doc/gnulib-tool.texi:472: Emergency stop.
 
@par 
 
   }
@doitemize ...1}@setbox 0 = @hbox {@itemcontents }
  @ifx @itemcontents @empty ...
l.472 @itemize @asis

/tmp/gnulib/doc/gnulib-tool.texi:472:  ==> Fatal error occurred, no output PDF 
file produced!
Transcript written on gnulib.log.
/arch/x86_64-linux-gnu/gnu-inst-texinfo/7.1/bin/texi2dvi: pdfetex exited with 
bad status, quitting.
make: *** [Makefile:34: gnulib.pdf] Error 1


Here are four good reasons for supporting @itemize @asis:

  * @table @asis is supported, see [1]
  "You may use the @asis command as an argument to @table.
   @asis is a command that does nothing: ..."

  * In HTML and info modes, 'makeinfo' does not produce an error for
@itemize @asis.

  * Several packages use @itemize @asis in their documentation: [2]

  * The workaround, which is to use @w{} instead of @asis, is hard to find [3].

Bruno

[1] 
https://www.gnu.org/software/texinfo/manual/texinfo/html_node/_0040table.html
[2] https://codesearch.debian.net/search?q=%40itemize+%40asis=1
[3] 
https://git.savannah.gnu.org/gitweb/?p=emacs.git;a=commitdiff;h=49ffdce87c1a2502af6f6459d1ecf10fe0104530

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

[Bruno Haible]

Gavin Smith wrote:
> It is surprising it worked as well as it did with mixing the two different
> struct definitions.

Yes. Probably because the alignment only matters on sparc64 and ia64 machines,
and because no new features were added to this module in 20 years.

> Thanks for the detailed investigation.  Will this be fixed in gnulib at
> some point?

Yes, I expect so.

Bruno

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

[Bruno Haible]

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

 The scope
 -

It is visible on CPUs that are
  - big-endian,
  - 64-bit,
  - not allowing unaligned accesses (this excludes powerpc64),
thus only on sparc64.

It is visible only on glibc systems. So, only on Linux/glibc/sparc64.

 The workaround
 --

Is attached.

 The explanation
 ---

The code in tree.c does not set the alignment explicitly; it uses the
DEFAULT_ALIGNMENT, which is 16. ('long', 'double', 'void *' all have
an __alignof__ of 8, and 'long double' has an __alignof__ of 16).

The code in tree.c is meant to use the code from gnulib's obstack.h
and obstack.c. obstack.c is compiled to libgnu_la-obstack.o, which is
then included in tp/Texinfo/XS/.libs/Parsetexi.so. Perl loads this
shared library via dlopen().

glibc and Parsetexi.so each define the obstack ABI symbols (_obstack_begin,
_obstack_begin_1, _obstack_newchunk, _obstack_free, etc.). Which of
the symbols "wins" at run time, depends on the flags passed to dlopen().
Apparently perl does not pass the RTLD_DEEPBIND flag. Therefore the
symbols from glibc take precedence. So, tree.c uses
  - the obstack.h *macros* from gnulib, but
  - the obstack *functions* from glibc.
The obstack facilities from gnulib and from glibc are nearly the same.
They use a 'struct obstack' with very similar layout. The only relevant
difference is that (on a 64-bit platform)

  - gnulib's struct obstack has a member

unsigned long alignment_mask;

  - glibc's struct obstack instead has two members

unsigned int alignment_mask;
unsigned int __padding;

(The padding is there because the next member is a pointer, which
has alignment 8, see above.)

So, what happens is that during initialization of the obstack (variable
'obs_element' in tree.c) the glibc function _obstack_begin sets the
alignment_mask to DEFAULT_ALIGNMENT - 1, that is 0xf. The __padding member
is apparently 0.

Then, in the function alloc_element of tree.c, obstack_alloc - which is a
macro! - uses the gnulib struct layout and accesses the alignment_mask which
has a value 0xf. __PTR_ALIGN with an alignment mask of 0xf
does not change the bits 31..0 of the pointer. Since tree.c also contains
a call
  obstack_alloc (_element, sizeof (int))
obstack_alloc returns a value that is ≡4 mod 8. tree.c then attempts to
access a pointer there, and this crashes with SIGBUS since it's not ≡0 mod 8.

 The root cause
 --

Gnulib generally uses idioms for overriding functions that are safe to use
in shared libraries and will avoid collisions. This is the business with
  REPLACE_FOO=1
and
  #define foo rpl_foo
and so on.

But the Gnulib module 'obstack' has never been updated to use these idioms.
It is still at the state of 1997 and uses a clunky _OBSTACK_INTERFACE_VERSION
mechanism.


Bruno

--- texinfo-7.1/tp/Texinfo/XS/gnulib/lib/obstack.h.bak	2023-08-13 22:10:03.0 +0200
+++ texinfo-7.1/tp/Texinfo/XS/gnulib/lib/obstack.h	2023-11-14 20:30:55.584463250 +0100
@@ -164,6 +164,12 @@
 # endif
 #endif
 
+#define _obstack_begin rpl_obstack_begin
+#define _obstack_newchunk rpl_obstack_newchunk
+#define _obstack_allocated_p rpl_obstack_allocated_p
+#define _obstack_free rpl_obstack_free
+#define _obstack_memory_used rpl_obstack_memory_used
+
 #ifdef __cplusplus
 extern "C" {
 #endif

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

[Bruno Haible]

Hi Jeffrey,

> On SPARC, 64-bit words can be loaded and saved through one of two
> instructions. The first version is optimized, the second version is
> not. The optimized version is faster, but the 64-bit words have to be
> aligned to 8-byte boundaries. I.e., naturally aligned.
> 
> If you are performing unaligned loads of 64-bit words, then you have
> to specify the compiler option -xmemalign=4i. -xmemalign=4i will
> generate the inefficient load, but it will avoid the SIGBUS.
> 
> When using the default toolchain settings, -xmemalign=8s is used,
> which causes the toolchain to use the optimized loads. I think that is
> what is generating the UBsan finding "runtime error: member access
> within misaligned address ... which requires 8 byte alignment."
> 
> Also see "3.4.151 –xmemalign[=]",
> , in the
> Solaris manual.

I know that you wanted to be helpful, but these details about the Solaris
Studio compiler option miss the point.

  * We are discussing a problem on Linux/glibc/sparc64 [1][2], not on Solaris.

  * For gnulib, we generally assume the default compiler settings,
except for a few essentially mandatory options on some platforms.[3]
It is futile to even read about '-xmemalign' and similar options
because
  - Gnulib cannot make use of them without excessive Makefile.am hacking.
  - Gnulib cannot support people who use such arbitrary compiler options,
as it would vastly increase the number of build configurations that
we would need to support.

We can use compiler-specific built-ins, intrinsics, asms, etc. because
that is limited to the .h / .c file source code. But not compiler-specific
options.

Bruno

[1] https://lists.gnu.org/archive/html/bug-texinfo/2023-11/msg0.html
[2] https://lists.gnu.org/archive/html/bug-texinfo/2023-11/msg00076.html
[3] https://gitlab.com/ghwiki/gnow-how/-/wikis/Platforms/Configuration

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

[Bruno Haible]

Sam James wrote:
> It appears that the obstack gnulib module is the culprit.

When I compile texinfo-7.1 in such a way that is uses the obstack facility
from glibc (via 'gl_cv_func_obstack=yes ../configure ...'), I see the same
bus error as in a build where the obstack facility comes from gnulib.

Therefore, if it is a bug in gnulib, it is also a bug in glibc.

But since obstack_alignment_mask is explicitly documented [1] as a means to
change the alignment, I wonder whether it is a bug at all?

[1] also says: "By default, this boundary is aligned so that the object can
hold any type of data." Needs to be investigated in more depth...

Bruno

[1] 
https://www.gnu.org/software/libc/manual/html_node/Obstacks-Data-Alignment.html

CC and CFLAGS are ignored by part of the build

[Bruno Haible]

Hi,

I'm trying to build texinfo-7.1 on Linux/sparc64, in order to debug a problem.
I configured the package with

CC="gcc -fsanitize=undefined" \
CFLAGS="-O0 -fno-omit-frame-pointer -ggdb" \
gl_cv_func_obstack=yes \
../configure --prefix=$HOME/prefix64 \
 CPPFLAGS="-I$HOME/prefix64/include -Wall" \
 LDFLAGS="-L$HOME/prefix64/lib"

and then, in the tp/Texinfo/XS/ subdirectory, under gdb, I get stack
frames like this one:

#2  0xf801012ec09c in setup_document_root_and_before_node_section ()
at ../../../../tp/Texinfo/XS/parsetexi/parser.c:523
523   add_to_element_contents (document_root, before_node_section);
(gdb) info locals
before_node_section = 0x127cf54
document_root = 

Apparently some optimization options were still in effect. And indeed,
the file tp/Texinfo/XS/config.status contains these lines:

CC='sparc64-linux-gnu-gcc'
compiler='sparc64-linux-gnu-gcc'
LTCC='sparc64-linux-gnu-gcc'
compiler='sparc64-linux-gnu-gcc'
S["CPP"]="sparc64-linux-gnu-gcc -E"
S["ac_ct_CC"]="sparc64-linux-gnu-gcc"
S["CC"]="sparc64-linux-gnu-gcc"
S["PERL_CONF_cc"]="sparc64-linux-gnu-gcc"
S["PERL_CONF_optimize"]="-O2 -g"

Per the GNU Coding Standards [1], when I specify CC and CFLAGS, it should
override the package's defaults.

I understand that perl comes with its own installation and that building
code that can be dynamically loaded by perl can be challenging. But the
CC and CFLAGS values that I have specified are ABI-compatible with
the ones that perl wants. Therefore I expect them to be obeyed.

Bruno

[1] https://www.gnu.org/prep/standards/html_node/Command-Variables.html

Re: c32width gives incorrect return values in C locale

[Bruno Haible]

[CCing bug-libunistring]
Gavin Smith wrote:
> I did not understand why uc_width was said to be "locale dependent":
> 
>   "These functions are locale dependent."
> 
> - from 
> .

That's because some Unicode characters have "ambiguous width" — width 1 in
Western locales, width 2 is East Asian locales (for historic and font choice
reasons).

> I also don't understand the purpose of the "encoding" argument -- can this
> always be "UTF-8"?

Yes, it can be always "UTF-8"; then uc_width will always choose width 1 for
these characters.

> I'm also unclear on the exact relationship between the types char32_t,
> ucs4_t and uint32_t.  For example, uc_width takes a ucs4_t argument
> but u8_mbtouc writes to a char32_t variable.  In the code I committed,
> I used a cast to ucs4_t when calling uc_width.

These types are all identical. Therefore you don't even need to cast.

  - char32_t comes from  (ISO C 11 or newer).
  - ucs4_t comes from GNU libunistring.
  - uint32_t comes from .

Bruno

Re: c32width gives incorrect return values in C locale

[Bruno Haible]

[CCing bug-gnulib]
Gavin Smith wrote:
> > I guess you will need to look at the Unicode characters that you pass to 
> > c32width,
> > and whether you get return values < 1 for some of them.
> 
> It is locale-dependent!
> 
> It looks like c32width is simply being redirected to wcwidth which then
> doesn't work properly with LC_ALL=C.  This is from the gnulib module
> c32width.
> 
> I don't know if there is an easy way to make a self-contained example
> to show the difference, because it needs all the gnulib Makefile machinery,
> but the difference shows up for any non-ASCII character.  If I add a line
> like
> 
>  fprintf (stderr, "width of [%4.0lx] is %d (remaining %s)\n",
> (long) wc, width, q);
> 
> in the right place in the code, where width is the result of c32width,
> then the output looks like
> 
> width of [  40] is 1 (remaining @)
> width of [  4f] is 1 (remaining OE )
> width of [  45] is 1 (remaining E )
> width of [ 152] is -1 (remaining Œ)
> width of [  28] is 1 (remaining (Œ)
> 
> for LC_ALL=C, but
> 
> width of [  40] is 1 (remaining @)
> width of [  4f] is 1 (remaining OE )
> width of [  45] is 1 (remaining E )
> width of [ 152] is 1 (remaining Œ)
> width of [  28] is 1 (remaining (Œ)
> 
> otherwise (LC_ALL=en_GB.UTF-8).

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 want texinfo to work on UTF-8 encoded text with characters outside
the repertoire of the current locale, you'll need the libunistring functions,
documented in
.
Namely, replace c32width with uc_width.

Bruno

Re: Locale-independent paragraph formatting

[Bruno Haible]

> > From: Gavin Smith 
> > Date: Thu, 9 Nov 2023 21:26:11 +
> > 
> > I have just pushed a commit (e3a28cc9bf) to use gnulib/libunistring
> > functions instead of the locale-dependent functions mbrtowc and wcwidth.
> > This allows for a significant simplification as we do not have to try
> > to switch to a UTF-8 encoded locale.
> > 
> > I was not sure about how to put a char32_t literal in the source code.
> > For example, where we previously had L'a' as a literal wchar_t letter 'a',
> > I changed this to U'a'.  I could not find very much information about this
> > online or whether this would be widely supported by C compilers.  The U 
> > prefix
> > for char32_t is mentioned in a copy of the C11 standard I found online and
> > also in a C23 draft.

My answer is at
.

Eli Zaretskii wrote:
> OTOH, the char32_t type is not supported by this GCC, not even if I
> use -std=gnu2x.  Maybe we should use uint_least32_t instead?

The char32_t type is provided by Gnulib's 'uchar' module, if the system
does not have it.

Bruno

Re: MinGW "info" program broken?

[Bruno Haible]

Eli Zaretskii wrote:
> > It happens also with the mingw-w64 version 5.0.3 build. Let me 
> > investigate...
> 
> Is this build with UCRT or with MSVCRT?

The mingw-w64 5.0.3 built ginfo.exe is linked with MSVCRT.

Only the MSVCRT built ginfo.exe is linked with the various api-ms-win-crt-*.dll,
that make up the so-called UCRT.

Bruno

Re: Texinfo 7.0.94 on native Windows

[Bruno Haible]

Eli Zaretskii wrote:
> _popen accepts a MODE argument which can be used to control that, see
> 
>   
> https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/popen-wpopen?view=msvc-170
> 
> We use this in the stand-alone Info reader, for example, in this
> snippet from info/filesys.c:
> 
>   stream = popen (command, FOPEN_RBIN);

This is good. But there are these two occurrences of popen():

1)
info/man.c:
fpipe = popen (cmdline, "r");

Should better use FOPEN_RBIN as well.

2)
info/session.c:
printer_pipe = fopen (++print_command, "w");
  printer_pipe = popen (print_command, "w");

Should better use FOPEN_WBIN.

Bruno

Re: MinGW "info" program broken?

[Bruno Haible]

Eli Zaretskii wrote:
> The stand-alone Info reader built with MinGW works
> flawlessly for me.
> 
> > I had understood that "info" was running well on MinGW so it would be worth
> > understanding any differences between yours and Bruno's setup.
> 
> I'm indeed curious why this happens with the MSVC build.

It happens also with the mingw-w64 version 5.0.3 build. Let me investigate...

Bruno

Re: MinGW "info" program broken?

[Bruno Haible]

Gavin Smith wrote:
> I had understood that "info" was running well on MinGW so it would be worth
> understanding any differences between yours and Bruno's setup.

I'm usually building with mingw-w64 5.0.3.

Whereas Eli (AFAIK) often builds with the older mingw from the now-defunct
mingw.org site. Correct me if I'm wrong, Eli.

Bruno

Re: Texinfo 7.0.94 on native Windows

[Bruno Haible]

Eli Zaretskii wrote:
> > For 'popen' and 'pclose', one needs the gnulib modules 'popen' and 'pclose',
> > respectively.
> 
> Windows has _popen and _pclose, which can be used instead.

_popen uses text mode, not binary mode, by default, AFAIK. This can be
problematic.

Bruno

Re: Texinfo 7.0.94 on native Windows

[Bruno Haible]

On mingw 5.0.3, there are no test failures any more.
A big improvement, compared to 7.0.90 (see my earlier report at
<https://lists.gnu.org/archive/html/bug-texinfo/2023-08/msg00030.html>).

With MSVC 14 (64-bit) instead of mingw, though, there are compilation
errors and warnings:

C:\cygwin64\home\bruno\texinfo-7.0.94\info\man.c(439): warning C4047: '=': 
'FILE *' differs in levels of indirection from 'int'
C:\cygwin64\home\bruno\texinfo-7.0.94\info\man.c(491): error C2079: 'timeout' 
uses undefined struct 'timeval'

C:\cygwin64\home\bruno\texinfo-7.0.94\info\tilde.c(45): warning C4312: 'type 
cast': conversion from 'int' to 'passwd *' of greater size
C:\cygwin64\home\bruno\texinfo-7.0.94\info\tilde.c(47): error C2037: left of 
'pw_dir' specifies undefined struct/union 'passwd'
C:\cygwin64\home\bruno\texinfo-7.0.94\info\tilde.c(85): error C2037: left of 
'pw_dir' specifies undefined struct/union 'passwd'
C:\cygwin64\home\bruno\texinfo-7.0.94\info\tilde.c(85): error C2198: 'strlen': 
too few arguments for call
C:\cygwin64\home\bruno\texinfo-7.0.94\info\tilde.c(87): error C2037: left of 
'pw_dir' specifies undefined struct/union 'passwd'
C:\cygwin64\home\bruno\texinfo-7.0.94\info\tilde.c(87): error C2198: 'strcpy': 
too few arguments for call

C:\cygwin64\home\bruno\texinfo-7.0.94\info\filesys.c(416): warning C4047: '=': 
'FILE *' differs in levels of indirection from 'int'

install-info.obj : error LNK2019: unresolved external symbol popen referenced 
in function open_possibly_compressed_file
install-info.obj : error LNK2019: unresolved external symbol pclose referenced 
in function readfile

For 'popen' and 'pclose', one needs the gnulib modules 'popen' and 'pclose',
respectively.

For 'timeval', one needs the gnulib module 'sys_time'.

Then, some link errors are seen:

man.obj : error LNK2019: unresolved external symbol 
select_used_without_including_sys_select_h referenced in function read_from_fd
session.obj : error LNK2001: unresolved external symbol 
select_used_without_including_sys_select_h
session.obj : error LNK2019: unresolved external symbol ioctl referenced in 
function info_gather_typeahead

To resolve this, one needs the gnulib module 'select'.

Thus, I'm arriving at the following changes, that make texinfo work with MSVC,
like it does with mingw:
  - "make check" passes.
  - The behaviour of the 'ginfo' program on MSVC is the same as on mingw,
albeit not really useful currently: './info -f texinfo.info' spits out
the entire manual to stdout at once. It looks like the device gets set
to stdout, or there is no knowledge about the terminal window's height,
or something like that.

Note the preprocessor predefs:
  - __MINGW32__ is defined on mingw (both 32-bit and 64-bit Windows),
  - _WIN32 is defined on native Windows (i.e. Windows except Cygwin),
also both 32-bit and 64-bit. That includes mingw.
See <https://github.com/cpredef/predef>.

I'm not saying that it's perfect. For example, the function pause_or_input
has specific code for native Windows; thus the socket-able code with select()
on stdin could probably be disabled? (This applies to both mingw and MSVC.)

Note: I wouldn't push for these changes before the 7.1 release, since in
particular the 'select' module can trigger behaviour changes. Rather, this
is post-7.1 stuff IMO.

Bruno



0001-MSVC-port-part-1-Ran-gnulib-tool-add-import-popen-pc.patch.gz
Description: application/gzip
>From c89961391cd3ad616cdd457c89c25f22c3213713 Mon Sep 17 00:00:00 2001
From: Bruno Haible 
Date: Sun, 15 Oct 2023 12:30:04 +0200
Subject: [PATCH 2/8] MSVC port, part 2: Accommodate the added gnulib modules.

* configure.ac: Don't test for sys/time.h, since gnulib now provides it.
* info/man.c: Assume that sys/time.h. Also include , for the
select() function.
* info/session.c: Likewise.
* info/Makefile.am (LDADD): Add $(SELECT_LIB), needed for the 'select' module.
---
 configure.ac |  2 +-
 info/Makefile.am |  3 +++
 info/man.c   |  3 +--
 info/session.c   | 11 ++-
 4 files changed, 7 insertions(+), 12 deletions(-)

diff --git a/configure.ac b/configure.ac
index 7fa457deb2..bd34937e06 100644
--- a/configure.ac
+++ b/configure.ac
@@ -220,7 +220,7 @@ AC_SUBST([DIFF_A_OPTION])
 # Checks for header files.
 AC_CHECK_HEADERS(io.h pwd.h \
   termcap.h termios.h unistd.h \
-  sys/ioctl.h sys/time.h sys/wait.h)
+  sys/ioctl.h sys/wait.h)
 
 AC_SYS_POSIX_TERMIOS
 
diff --git a/info/Makefile.am b/info/Makefile.am
index f57b341ea2..0cc770413f 100644
--- a/info/Makefile.am
+++ b/info/Makefile.am
@@ -29,6 +29,9 @@ LDADD = $(top_builddir)/gnulib/lib/libgnu.a $(TERMLIBS)
 # for various gnulib modules
 LDADD += $(LIBINTL) $(LIBICONV) $(LIBC32CONV) $(LIBUNISTRING) $(LIBTHREAD)
 
+# for select gnulib module
+LDADD += $(SELECT_LIB)
+
 # for hard-locale gnulib module which is brought in indirectly
 LDADD += $(HARD_LOCALE_LIB) $(SETLOCALE_NULL_LIB)
 
diff --git a/info/man.c b/info/man.c
index 49a0d0636f..cbb8451cb7 1006

Re: Texinfo 7.0.93 pretest available

[Bruno Haible]

Hi Gavin,

> The module shouldn't load if it can't switch to a UTF-8 locale.  xspara_init
> returns a different value if these attempts fail leading the code loading
> the module (in Texinfo::XSLoader) to fall back to the pure Perl version.

Ah, maybe this is what did not work in Eli's case on mingw?

I wrote:
> > The only portable way out is to use iconv() instead of setlocale(), 
> > mbrtowc(),
> > etc. This is how e.g. gettext's PO parser does it:
> > https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=blob;f=gettext-tools/src/po-lex.c;h=22d08849206b812b18ace9de7629bb95a9d71c3c;hb=c9af3e4eeccc178a0833754e3d8c7083591e75ba
> > lines 127..595. You will also find a function mb_width in there.

Given that the only encoding you want to deal with is UTF-8, Eli's suggestion
to use GNU libunistring is better than my iconv() suggestion. It has functions
for width determination:
https://www.gnu.org/software/libunistring/manual/html_node/uniwidth_002eh.html

> but I doubt it is urgent to do before the release, as the current approach,
> however flawed, has been in place and worked fairly well for a long time
> (since the XS paragraph module was written).

Well, it does not work on Windows.

I agree with you that it's not urgent to do before the 7.1 release, since
the Windows port is work-in-progress.

Bruno

Re: Texinfo 7.0.93 pretest available

[Bruno Haible]

Eli Zaretskii wrote:
> I think we should first explore a better
> alternative: use UTF-8 functions everywhere, without relying on the
> locale-aware functions of libc, such as wcwidth.  For example, instead
> of wcwidth, we could use uc_width.
> 
> Is it feasible to use UTF-8 in texi2any disregarding the locale, and
> use libunistring or something similar for the few functions we need in
> the extensions that are required to deal with non-ASCII characters?
> If we can do that, it will work on all systems, including Windows.

+1

Bruno

Re: Texinfo 7.0.93 pretest available

[Bruno Haible]

Gavin Smith wrote:
> It is supposed to attempt to force the locale to a UTF-8 locale.  You
> can see the code in xspara_init that attempts to change the locale.  There
> is also a comment before xspara_add_text:
> 
>   "This function relies on there being a UTF-8 locale in LC_CTYPE for
>   mbrtowc to work correctly."

That's an inherently unportable thing. You can't just force an UTF-8
locale if the system does not have it.

> For MS-Windows there is the w32_setlocale function that may use something
> different:
> 
>   /* Switch to the Windows U.S. English locale with its default
>  codeset.  We will handle the non-ASCII text ourselves, so the
>  codeset is unimportant, and Windows doesn't support UTF-8 as the
>  codeset anyway.  */
>   return setlocale (category, "ENU");
> 
> mbrtowc has its own override which handle UTF-8.

On native Windows, with the (lots of!) Gnulib overrides, with the MSVC compiler
the locale French_France.65001 is a UTF-8 locale. But with mingw this does
not work; probably something in mingw's setlocale() works differently than
in MSVC's setlocale().

In summary: On mingw there is no UTF-8 locale, and you cannot force it.

The only portable way out is to use iconv() instead of setlocale(), mbrtowc(),
etc. This is how e.g. gettext's PO parser does it:
https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=blob;f=gettext-tools/src/po-lex.c;h=22d08849206b812b18ace9de7629bb95a9d71c3c;hb=c9af3e4eeccc178a0833754e3d8c7083591e75ba
lines 127..595. You will also find a function mb_width in there.

Note that switching from locales to hand-written encoding support is a
major change; I wouldn't recommend to do it before Texinfo 7.1.

Bruno

Re: Texinfo 7.0.93 pretest available

[Bruno Haible]

Eli Zaretskii wrote:
> > From: Bruno Haible 
> > Cc: bug-texinfo@gnu.org
> > Date: Mon, 09 Oct 2023 18:15:05 +0200
> > 
> > Eli Zaretskii wrote:
> > > unless the locale's codeset is UTF-8, any character that is not
> > > printable _in_the_current_locale_ will return -1 from wcwidth.  I'm
> > > guessing that no one has ever tried to run the test suite in a
> > > non-UTF-8 locale before?
> > 
> > I just tried it now: On Linux (Ubuntu 22.04), in a de_DE.UTF-8 locale,

Oops, typo: What I tested was the de_DE.ISO-8859-1 locale:
$ export LC_ALL=de_DE.ISO-8859-1

> > texinfo 7.0.93 build fine and all tests pass.

And likewise on FreeBSD 13.2 with
$ export LC_ALL=de_DE.ISO8859-1

> > This character is U+0237 LATIN SMALL LETTER DOTLESS J. It *should* be
> > recognized as having a width of 1 in all implementations of wcwidth.
> 
> But if U+0237 cannot be represented in the locale's codeset, its width
> can not be 1, because it cannot be printed.  This is my interpretation
> of the standard's language (emphasis mine):
> 
>   DESCRIPTION
> 
>   The wcwidth() function shall determine the number of column
>   positions required for the wide character wc. The application
>   shall ensure that the value of wc is a character representable
>   as a wchar_t, and is a wide-character code corresponding to a
>   valid character in the current locale.
>   ^
>   RETURN VALUE
> 
>   The wcwidth() function shall either return 0 (if wc is a null
>   wide-character code), or return the number of column positions
>   to be occupied by the wide-character code wc, or return -1 (if
>   wc does not correspond to a printable wide-character code).
>  ^^
> Since U+0237 is not printable in my locale (it isn't supported by the
> system codepage), the value -1 is correct.  Am I missing something?

True. But why don't we see the same test failure on glibc and on FreeBSD
systems, then, in a locale with ISO-8859-1 encoding?

> > This "simpler approximation" would not return a good result when wc
> > is a control character (such as CR, LF, TAB, or such). It is important
> > that the caller of wcwidth() or wcswidth() is able to recognize that
> > the string as a whole does not have a definite width.
> 
> It is still better than returning -1, don't you agree?

No, I don't agree. Returning -1 tells the caller "watch out, you cannot
assume anything about printed outline of this string".

> But for some reason you completely ignored my more general comment
> about what Texinfo needs from wcwidth.

That's because I am not familiar with the Texinfo code. I don't know
whether and where Texinfo calls wcwidth(), and I don't know with which
expectations it does so.

Bruno

Re: Texinfo 7.0.93 pretest available

[Bruno Haible]

Eli Zaretskii wrote:
> unless the locale's codeset is UTF-8, any character that is not
> printable _in_the_current_locale_ will return -1 from wcwidth.  I'm
> guessing that no one has ever tried to run the test suite in a
> non-UTF-8 locale before?

I just tried it now: On Linux (Ubuntu 22.04), in a de_DE.UTF-8 locale,
texinfo 7.0.93 build fine and all tests pass.

> Yes, quite a few characters return -1 from wcwidth, in particular the
> ȷ character above (which explains the above difference).

This character is U+0237 LATIN SMALL LETTER DOTLESS J. It *should* be
recognized as having a width of 1 in all implementations of wcwidth.
There's no reason for it to have a width of -1, since it's not a control
character.
There's no reason for it to have a width of 0, since it's not a combining
mark or a non-spacing character.
There's no reason for it to have a width of 2, since it's not a CJK character
and not in a Unicode range with many CJK characters.

>   /* Otherwise, fall back to the system's wcwidth function.  */
> #if HAVE_WCWIDTH
>   return wcwidth (wc);
> #else
>   return wc == 0 ? 0 : iswprint (wc) ? 1 : -1;
> #endif
> }
> }
> 
> 
> I don't think the above logic in Gnulib's wcwidth (which basically
> replicates the logic in any reasonable wcwidth implementation, so is
> not specific to Gnulib) fits what Texinfo needs.  Texinfo needs to be
> able to produce output independently of the locale.  What matters to
> Texinfo is the encoding of the output document, not the locale's
> codeset.  So I think we should call uc_width when the output document
> encoding is UTF-8 (which is the default, including in the above test),
> regardless of the locale's codeset.  Or we could use a simpler
> approximation:
> 
>   return wc == 0 ? 0 : iswcntrl (wc) ? 0 : 1;

This "simpler approximation" would not return a good result when wc
is a control character (such as CR, LF, TAB, or such). It is important
that the caller of wcwidth() or wcswidth() is able to recognize that
the string as a whole does not have a definite width.

Bruno

Re: Texinfo 7.0.93 pretest on CentOS Stream 9

[Bruno Haible]

On CentOS Stream 9, the configuration aborts right away:

  checking Perl version and modules... no
  configure: error: perl >= 5.8.1 with Encode, Data::Dumper and 
Unicode::Normalize required by Texinfo.

This is an improvement, compared to my previous report
https://lists.gnu.org/archive/html/bug-texinfo/2023-09/msg00041.html .

After executing the command

  $ sudo dnf install perl-Encode perl-Data-Dumper perl-Unicode-Normalize

the build works fine and all tests pass.

Bruno

Re: Texinfo 7.0.93 pretest

[Bruno Haible]

The compilation succeeds, and "make check" has all tests pass on:
* Linux:
  - Ubuntu 22.04
  - Debian 9.1
  - Debian 12
  - OpenSUSE Leap 15.5
  - Slackware 15
  - CentOS 8-stream
(This means the previously reported failure
 https://lists.gnu.org/archive/html/bug-texinfo/2023-09/msg00040.html
 is fixed.)
* NetBSD 9.0
  (This means the previously reported FTBFS
   https://lists.gnu.org/archive/html/bug-texinfo/2023-09/msg00042.html
   is fixed.)
* AIX 7.3.1
  (This means the previously reported FTBFS
   https://lists.gnu.org/archive/html/bug-texinfo/2023-09/msg00039.html
   is fixed.)

Bruno

Re: Texinfo 7.0.92 pretest on AIX 7.3.1

[Bruno Haible]

Gavin Smith wrote:
> Once a pretest is out and tested, and builds successfully on some platforms,
> I am loth to update gnulib again and risk breaking the build.
> ...
> At the time of a release, the Gnulib checkout is set in stone.  It will not
> be updated as a matter of course for any bug-fix releases; it would only
> be deliberately updated if there was an apparent bug or reported compatability
> issue.  This is to reassure users and distributors that we are making
> minimal changes in bug-fix releases.  Many Gnulib changes may be
> inconsequential or not relevant for Texinfo.  In view of this, there seems
> to be little downside to fixing the Gnulib checkout at the time of the
> first pretest, rather than at the eventual release.

This makes perfect sense.

> I did not know about the stable branches of gnulib, and using one of these
> is a possibility, but this might reduce testing of gnulib itself.  In the
> past, Texinfo prereleases have occasionally found bugs in gnulib, and it
> seems that using a recent development version of gnulib is a way to improve
> the quality of gnulib.

That's true. By using the master branch of gnulib, you help its QA.
By using a stable branch of gnulib, you leave that QA work to others. :-)

> Another way, I guess, is for me to check the recent gnulib ChangeLog for
> any relevant changes, but this would be very hard for me to do, I expect, as
> I wouldn't know which changes were important to include.

Yes.

Bruno

Re: Texinfo 7.0.92 pretest on NetBSD 9.0

[Bruno Haible]

Hi Patrice,

> As a side note, it would have been better to have a specific variable
> like LTLIBUNISTRING instead of using the global CPPFLAGS, but it is not
> a big deal either.

The absence of such a variable INCLIBUNISTRING is a trade-off between
convenience and complexity.

-L and -Wl options are collected in $LIBUNISTRING or $LTLIBUNISTRING
because typically only selected binaries of a package need to be linked
with libunistring; the other binaries should not see an increased startup
time or memory footprint.

The situation is different for -I options:
  - It's harmless to have additional (possibly unused) -I options in $CPPFLAGS.
  - It simplifies the Makefile to have all -I options in $CPPFLAGS.
  - It also simplifies further configure tests if there's no need to
explicitly add $INCLIBUNISTRING to CPPFLAGS.

I first did it like this with libintl, ca. 25 years ago, and this approach
to modify CPPFLAGS works fine, except there were problems with config.cache
and early (old) versions of autoconf IIRC.

Bruno

Re: Texinfo 7.0.92 pretest on CentOS 8-stream

[Bruno Haible]

Patrice Dumas wrote:
> > So, as I understand it, this test failure will remain.
> 
> Actually it should not, the test should have been skipped, it was
> supposed to be fixed by this commit:
> 
> https://git.savannah.gnu.org/cgit/texinfo.git/commit/?id=e34a8d6b66d0518a2c1673da62c56b60f87151e3

This commit fixes it; thanks. But I was testing the 7.0.92 from a few days ago.

Bruno

Re: Texinfo 7.0.90 pretest on CentOS 8-stream (Unicode::Collate)

[Bruno Haible]

Patrice Dumas wrote:
> > FAIL: different_encodings.sh
> 
> There was the same kind of errors on N Beebe builds (I missed your
> original report).  It is is supposed to be fixed by
> https://git.savannah.gnu.org/cgit/texinfo.git/commit/?id=e34a8d6b66d0518a2c1673da62c56b60f87151e3

I confirm: With this patch, the test failure becomes a SKIP.

Bruno

Re: Texinfo 7.0.92 pretest on other platforms

[Bruno Haible]

The compilation succeeds, and "make check" has all tests pass on:
* Linux:
  - Ubuntu 22.04
  - Debian 9.1
  - Debian 12
  - OpenSUSE Leap 15.5
  - Slackware 15
  - Manjaro 17 (both in 32-bit and 64-bit mode)
* Alpine Linux 3.14
* GNU/Hurd
* macOS 12.5
* FreeBSD 13.2
* OpenBSD 7.2
* AIX 7.1 and 7.3.1 (both in 32-bit and 64-bit mode), after working around
  https://lists.gnu.org/archive/html/bug-texinfo/2023-09/msg00039.html
* Solaris 10 and 11.4 (both in 32-bit and 64-bit mode)
* Solaris 11 OmniOS (both in 32-bit and 64-bit mode)
* Solaris 11 OpenIndiana (both in 32-bit and 64-bit mode)
* Cygwin 2.9.0 (in 64-bit mode)

Bruno

Re: Texinfo 7.0.92 pretest on NetBSD 9.0

[Bruno Haible]

On NetBSD 9.0, with a GNU libiconv 1.0 installed, I see this build failure:

$ gmake
...
/bin/sh ../../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. 
-I../../../../../../tp/Texinfo/XS/gnulib/lib -I../.. -Wno-cast-qual 
-Wno-conversion -Wno-float-equal -Wno-sign-compare -Wno-undef 
-Wno-unused-function -Wno-unused-parameter -Wno-float-conversion 
-Wimplicit-fallthrough -Wno-pedantic -Wno-sign-conversion -Wno-type-limits 
-Wno-unsuffixed-float-constants  -MT libgnu_la-striconveh.lo -MD -MP -MF 
.deps/libgnu_la-striconveh.Tpo -c -o libgnu_la-striconveh.lo `test -f 
'striconveh.c' || echo 
'../../../../../../tp/Texinfo/XS/gnulib/lib/'`striconveh.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. 
-I../../../../../../tp/Texinfo/XS/gnulib/lib -I../.. -Wno-cast-qual 
-Wno-conversion -Wno-float-equal -Wno-sign-compare -Wno-undef 
-Wno-unused-function -Wno-unused-parameter -Wno-float-conversion 
-Wimplicit-fallthrough -Wno-pedantic -Wno-sign-conversion -Wno-type-limits 
-Wno-unsuffixed-float-constants -MT libgnu_la-striconveh.lo -MD -MP -MF 
.deps/libgnu_la-striconveh.Tpo -c 
../../../../../../tp/Texinfo/XS/gnulib/lib/striconveh.c  -fPIC -DPIC -o 
.libs/libgnu_la-striconveh.o
In file included from 
../../../../../../tp/Texinfo/XS/gnulib/lib/striconveh.c:29:0:
./unistr.h:21:10: fatal error: unitypes.h: No such file or directory
 #include "unitypes.h"
  ^~~~
compilation terminated.
*** Error code 1

Stop.
make[7]: stopped in /home/bruno/texinfo-7.0.92/build/tp/Texinfo/XS/gnulib/lib


In the scope of the main configure.ac, everything is fine: the top-level
build/Makefile has
  LIBUNISTRING_UNICASE_H = unicase.h
  LIBUNISTRING_UNICTYPE_H = unictype.h
  LIBUNISTRING_UNINORM_H = uninorm.h
  LIBUNISTRING_UNITYPES_H = unitypes.h
  LIBUNISTRING_UNIWIDTH_H = uniwidth.h
and thus all necessary .h files are generated in the build/gnulib/lib/ dir.

However, in the scope of the tp/Texinfo/XS/configure.ac, there is a problem:
* The build/tp/Texinfo/XS/Makefile has
LIBUNISTRING_UNICONV_H =
LIBUNISTRING_UNISTR_H = unistr.h
LIBUNISTRING_UNITYPES_H =
LIBUNISTRING_UNIWIDTH_H =
  So only unistr.h gets generated, but unitypes.h does not. This is the
  normal behaviour when the 'libunistring' module is in use.
* But you can see from the log above that no -I option is in use that
  allows the compiler to find the *installed* .
* The 'libunistring' module puts the necessary -I options into the CPPFLAGS
  variable, as documented in
  
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=m4/libunistring.m4;h=15702811764c2812ad5fe91c2407aff0a55603b9;hb=HEAD
* But in build/tp/Texinfo/XS/config.status the value of the CPPFLAGS
  variable is empty.

The origin of the bug is here:
$ grep -n CPPFLAGS= tp/Texinfo/XS/configure.ac /dev/null 
tp/Texinfo/XS/configure.ac:100:  CPPFLAGS=$PERL_EXT_CPPFLAGS
tp/Texinfo/XS/configure.ac:152:CPPFLAGS=$PERL_EXT_CPPFLAGS

Both of these statements throw away the -I options that the configuration
previously had put there.

Bruno



netbsd90-logs.tar.gz
Description: application/compressed-tar

Re: Texinfo 7.0.92 pretest on CentOS Stream 9

[Bruno Haible]

On CentOS Stream 9, "make check" fails with 52 test failures.

Find attached the log files.



centos9-logs.tar.gz
Description: application/compressed-tar

Re: Texinfo 7.0.92 pretest on CentOS 8-stream

[Bruno Haible]

On CentOS 8-stream, I still see this test failure:

FAIL: different_encodings.sh

Already reported in
https://lists.gnu.org/archive/html/bug-texinfo/2023-08/msg00053.html

Last time, you wrote:
> Even though there is
> a stub for Unicode::Collate, the tests will not all pass without it.
> "configure" prints a warning about index sorting so users should not be
> too surprised if the tests fail.

So, as I understand it, this test failure will remain.

Bruno

Re: Texinfo 7.0.92 pretest on AIX 7.3.1

[Bruno Haible]

On AIX 7.3.1, I see a compilation error:


/opt/freeware/bin/gcc -maix64 -DHAVE_CONFIG_H -I. -I../../../gnulib/lib 
-I../..   -I/home/haible/prefix64/include -Wall -D_THREAD_SAFE  -Wno-cast-qual 
-Wno-conversion -Wno-float-equal -Wno-sign-compare -Wno-undef 
-Wno-unused-function -Wno-unused-parameter -Wno-float-conversion 
-Wimplicit-fallthrough -Wno-pedantic -Wno-sign-conversion -Wno-type-limits 
-Wno-unsuffixed-float-constants -g -O2 -MT libgnu_a-argz.o -MD -MP -MF 
.deps/libgnu_a-argz.Tpo -c -o libgnu_a-argz.o `test -f 'argz.c' || echo 
'../../../gnulib/lib/'`argz.c
In file included from ./stddef.h:80,
 from ./string.h:55,
 from ./argz.h:26,
 from ../../../gnulib/lib/argz.c:21:
/opt/freeware/lib/gcc/powerpc-ibm-aix7.3.0.0/10/include/stddef.h:426:3: error: 
conflicting types for 'max_align_t'
  426 | } max_align_t;
  |   ^~~
In file included from ./string.h:55,
 from ./argz.h:26,
 from ../../../gnulib/lib/argz.c:21:
./stddef.h:70:14: note: previous declaration of 'max_align_t' was here
   70 | typedef long max_align_t;
  |  ^~~
make: 1254-004 The error code from the last command is 1.


This is already fixed by gnulib commit
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=17c85713388407841f5c9978ecb3ccaf34ef76f1
Interestingly, texinfo/tp/Texinfo/XS/gnulib/lib/stddef.in.h has the fix
but texinfo/gnulib/lib/stddef.in.h does not.

I would have expected that you have a policy regarding which gnulib
version to use (maybe the newest one, one week before release?
or one of the stable branches [1]?), and am surprised to see that
two parts of the texinfo git use different policies.

Bruno

[1] https://www.gnu.org/software/gnulib/manual/html_node/Stable-Branches.html

Re: "error: too deeply nested expressions" for large Perl input file

[Bruno Haible]

Gavin Smith wrote:
> In gettext 0.22, there is an error running xgettext with a large input
> file:
> 
> $ /usr/local/bin/xgettextHTML.pm 
> HTML.pm:8052: error: too deeply nested expressions
> 
> This makes "make update-po" break in the Texinfo package.

Thanks for the report. Fixed through .

> I have tried to reduce the input file to a minimal case by deleting
> chunks of the file but beyond a certain point the error disappears.

Yes, in this case, the problem appeared only when the input file is quite large.

Bruno

Re: Texinfo 7.0.90 pretest on CentOS 8-stream (Unicode::Collate)

[Bruno Haible]

Gavin Smith wrote:
> > On CentOS 8 and CentOS 8-stream, the build now succeeds, but there is 1 test
> > failure:
> > 
> > FAIL: different_encodings.sh
> > 
> > Find attached the tp/tests/many_input_files/test-suite.log.
> > 
> 
> Can you please send the contents of the file 'diffs/different_encodings.diff'
> which should be present after this test?

Here it is. It's the same in CentOS 8 and CentOS 8-stream, except for time
stamps.

Bruno
diff -u -r diffs/staging/different_encodings_res/char_latin1_latin1_in_refs.html different_encodings/char_latin1_latin1_in_refs.html
--- diffs/staging/different_encodings_res/char_latin1_latin1_in_refs.html	2023-08-18 14:51:07.0 +0200
+++ different_encodings/char_latin1_latin1_in_refs.html	2023-08-19 15:23:53.853435429 +0200
@@ -51,16 +51,16 @@
 Index EntrySection
 
 A
-Ä Ë Ï Ö Üç
 â ê î ô û Â Ê Î Ô Ûç
+Ä Ë Ï Ö Üç
 ä ë ï ö ü ÿç
 
 C
 çç
 
 E
-éç
 èç
+éç
 
 
 Jump to:   A
diff -u -r diffs/staging/different_encodings_res/char_utf8_latin1_in_refs.html different_encodings/char_utf8_latin1_in_refs.html
--- diffs/staging/different_encodings_res/char_utf8_latin1_in_refs.html	2023-08-18 14:51:07.0 +0200
+++ different_encodings/char_utf8_latin1_in_refs.html	2023-08-19 15:23:53.894435057 +0200
@@ -51,16 +51,16 @@
 Index EntrySection
 
 A
-Ä Ë Ï Ö Üç
 â ê î ô û Â Ê Î Ô Ûç
+Ä Ë Ï Ö Üç
 ä ë ï ö ü ÿç
 
 C
 çç
 
 E
-éç
 èç
+éç
 
 
 Jump to:   A

fix syntax error in doc/Makefile.am

[Bruno Haible]

Some 'make' programs give a syntax error when the lines that define the
commands for a target don't all start with a tab. The text editor that
I use (KDE kate) highlights such lines. This patch provides a fix.

Bruno
diff --git a/doc/Makefile.am b/doc/Makefile.am
index 69dc082a6e..e0d5209f84 100644
--- a/doc/Makefile.am
+++ b/doc/Makefile.am
@@ -177,9 +177,9 @@ wwwdoc-build:
 # http://www.gnu.org/software/texinfo/manual/
 wwwdoc-install:
 	cp -arf $(doctemp)/$(manual1) $(doctemp)/$(manual2) \
-$(doctemp)/$(manual3) $(doctemp)/$(manual4) \
-$(doctemp)/pod2texi.html \
-$(www_target)
+	$(doctemp)/$(manual3) $(doctemp)/$(manual4) \
+	$(doctemp)/pod2texi.html \
+	$(www_target)
 	$(MKDIR_P) $(www_target)/Pod/Simple
 	cp -arf $(doctemp)/Pod/Simple/Texinfo.html $(www_target)/Pod/Simple
 	ls -ltu $(www_target)/*/html_node | tail  # cvs rm -f obsolete files

Re: "make dist" error

[Bruno Haible]

Gavin Smith wrote:
> I've added rules for these and checked that they work in out-of-source
> builds, and with make distcheck.

Thanks.

Note that this Makefile.am does not have a .NOTPARALLEL pseudo-target,
therefore if people (not me, but someone else :) ) runs
"make -j 4 dist", two different "make" processes will be started
in the doc/refcard/ directory, leading to undefined results.
I think this can be avoided through the attached patch.

Bruno
diff --git a/doc/Makefile.am b/doc/Makefile.am
index 69dc082a6e..92b188cec4 100644
--- a/doc/Makefile.am
+++ b/doc/Makefile.am
@@ -57,11 +57,8 @@ refcard_files = refcard/Makefile refcard/txicmdcheck \
 refcard/txirefcard-a4.pdf refcard/txirefcard.pdf \
 		refcard/txirefcard.tex
 
-refcard/txirefcard.pdf: refcard/txirefcard.tex
-	(cd $(srcdir)/refcard && make)
-
-refcard/txirefcard-a4.pdf: refcard/txirefcard.tex
-	(cd $(srcdir)/refcard && make)
+refcard/txirefcard.pdf refcard/txirefcard-a4.pdf: refcard/txirefcard.tex
+	cd $(srcdir)/refcard && make
 
 # Include our texinfo.tex, not Automake's.
 EXTRA_DIST = epsf.tex texinfo.tex \

Re: Texinfo 7.0.90 pretest on AIX 7.3

[Bruno Haible]

Gavin Smith wrote:
> I have committed a
> change to use a temporary file in the same directory as the dir file,
> which is done by extending the name of the dir file.

Thanks. "make check" on AIX 7.3 now passes. No test failures.

Bruno

Re: Texinfo 7.0.90 pretest on CentOS 8-stream (Unicode::Collate)

[Bruno Haible]

Gavin Smith wrote:
> I've added such a stub and added a test to configure, so that a visible
> warning will be printed at the end of a configure run warning about missing
> Unicode::Collate.

On CentOS 8 and CentOS 8-stream, the build now succeeds, but there is 1 test
failure:

FAIL: different_encodings.sh

Find attached the tp/tests/many_input_files/test-suite.log.

Bruno
==
   GNU Texinfo 7.0.90: tp/tests/many_input_files/test-suite.log
==

# TOTAL: 9
# PASS:  4
# SKIP:  4
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

SKIP: tex_l2h.sh


Skipping HTML TeX tests that are not easily reproducible (../../../../tp/tests/many_input_files/tex_l2h.sh)
SKIP tex_l2h.sh (exit status: 77)

SKIP: tex_t4ht.sh
=

Skipping HTML TeX tests that are not easily reproducible
SKIP tex_t4ht.sh (exit status: 77)

FAIL: different_encodings.sh


+ cmd=' /usr/bin/perl -I ../../../../tp/tests/many_input_files/../.. -I ../../../../tp/tests/many_input_files/../../maintain/lib/Unicode-EastAsianWidth/lib/ -I ../../../../tp/tests/many_input_files/../../maintain/lib/libintl-perl/lib -I ../../../../tp/tests/many_input_files/../../maintain/lib/Text-Unidecode/lib/ -w ../../../../tp/tests/many_input_files/../../texi2any.pl --html --no-split --set-customization-variable '\''TEST 1'\'' --enable-encoding -c OUTPUT_CHARACTERS=1 --conf-dir ../../../../tp/tests/many_input_files/../../init --out different_encodings/ ../../../../tp/tests/many_input_files/../../t/input_files/char_latin1_latin1_in_refs.texi ../../../../tp/tests/many_input_files/../../t/input_files/char_utf8_latin1_in_refs.texi --force >> different_encodings/stdout_different_encodings.out 2>different_encodings/different_encodings.2'
+ echo ' /usr/bin/perl -I ../../../../tp/tests/many_input_files/../.. -I ../../../../tp/tests/many_input_files/../../maintain/lib/Unicode-EastAsianWidth/lib/ -I ../../../../tp/tests/many_input_files/../../maintain/lib/libintl-perl/lib -I ../../../../tp/tests/many_input_files/../../maintain/lib/Text-Unidecode/lib/ -w ../../../../tp/tests/many_input_files/../../texi2any.pl --html --no-split --set-customization-variable '\''TEST 1'\'' --enable-encoding -c OUTPUT_CHARACTERS=1 --conf-dir ../../../../tp/tests/many_input_files/../../init --out different_encodings/ ../../../../tp/tests/many_input_files/../../t/input_files/char_latin1_latin1_in_refs.texi ../../../../tp/tests/many_input_files/../../t/input_files/char_utf8_latin1_in_refs.texi --force >> different_encodings/stdout_different_encodings.out 2>different_encodings/different_encodings.2'
+ eval /usr/bin/perl -I ../../../../tp/tests/many_input_files/../.. -I ../../../../tp/tests/many_input_files/../../maintain/lib/Unicode-EastAsianWidth/lib/ -I ../../../../tp/tests/many_input_files/../../maintain/lib/libintl-perl/lib -I ../../../../tp/tests/many_input_files/../../maintain/lib/Text-Unidecode/lib/ -w ../../../../tp/tests/many_input_files/../../texi2any.pl --html --no-split --set-customization-variable ''\''TEST' '1'\''' --enable-encoding -c OUTPUT_CHARACTERS=1 --conf-dir ../../../../tp/tests/many_input_files/../../init --out different_encodings/ ../../../../tp/tests/many_input_files/../../t/input_files/char_latin1_latin1_in_refs.texi ../../../../tp/tests/many_input_files/../../t/input_files/char_utf8_latin1_in_refs.texi --force '>>' different_encodings/stdout_different_encodings.out '2>different_encodings/different_encodings.2'
++ /usr/bin/perl -I ../../../../tp/tests/many_input_files/../.. -I ../../../../tp/tests/many_input_files/../../maintain/lib/Unicode-EastAsianWidth/lib/ -I ../../../../tp/tests/many_input_files/../../maintain/lib/libintl-perl/lib -I ../../../../tp/tests/many_input_files/../../maintain/lib/Text-Unidecode/lib/ -w ../../../../tp/tests/many_input_files/../../texi2any.pl --html --no-split --set-customization-variable 'TEST 1' --enable-encoding -c OUTPUT_CHARACTERS=1 --conf-dir ../../../../tp/tests/many_input_files/../../init --out different_encodings/ ../../../../tp/tests/many_input_files/../../t/input_files/char_latin1_latin1_in_refs.texi ../../../../tp/tests/many_input_files/../../t/input_files/char_utf8_latin1_in_refs.texi --force
+ return_code=0
+ ret=0
+ '[' 0 '!=' 0 ']'
+ outdir=different_encodings
+ cp -pr different_encodings raw_out
+ dir=different_encodings
+ '[' -d ../../../../tp/tests/many_input_files/different_encodings_res ']'
+ rm -rf diffs/staging/different_encodings_res
+ cp -pr ../../../../tp/tests/many_input_files/different_encodings_res diffs/staging
+ chmod -R u+w diffs/staging/different_encodings_res
+ diff -u -r diffs/staging/different_encodings_res different_encodings
+ dif_ret=1
+ '[' 1 '!=' 0 ']'
+ echo 'D: diffs/different_encodings.diff'
D: diffs/different_encodings.diff
+ return_code=1
+ rm -rf
+ exit 1
FAIL different_encodings.sh (exit status: 1)

SKIP: 

"make dist" error

[Bruno Haible]

Hi,

I'm trying to create a texinfo tarball from the current git (for testing
on CentOS 8-stream...) and am getting this error:

$ ./autogen.sh
...
$ ./configure
...
$ make
...
$ make dist
...
make[3]: Entering directory 
'/media/develdata/www-archive/source/newest/texinfo-git/texinfo/doc'
make  distdir-am
make[4]: Entering directory 
'/media/develdata/www-archive/source/newest/texinfo-git/texinfo/doc'
make[4]: *** No rule to make target 'refcard/txirefcard-a4.pdf', needed by 
'distdir-am'.  Stop.

I can do
$ (cd doc/refcard && make txirefcard-a4.pdf)
Then the next one is:

$ make dist
...
make[3]: Entering directory 
'/media/develdata/www-archive/source/newest/texinfo-git/texinfo/doc'
make  distdir-am
make[4]: Entering directory 
'/media/develdata/www-archive/source/newest/texinfo-git/texinfo/doc'
make[4]: *** No rule to make target 'refcard/txirefcard.pdf', needed by 
'distdir-am'.  Stop.

I do:
$ (cd doc/refcard && make txirefcard.pdf)
Then "make dist" proceeds.

Suggestion: Add to doc/Makefile rules to recurse into the doc/refcard/
directory, in order to create these two files, when needed.

Bruno

Re: Texinfo 7.0.90 pretest on CentOS 8-stream (Unicode::Collate)

[Bruno Haible]

Patrice Dumas wrote:
> > https://lwn.net/Articles/348090/ "Re: Redhat perl != perl"
> > https://lwn.net/Articles/348084/ "On properly packaging perl"
> 
> This seems to be an old change that was reverted afterwards.

This thread was in 2009. Since things are fine in CentOS 6 and 7, probably
they reverted it around 2010 (before CentOS 6) and did the same thing again
around 2014 (between CentOS 7 and CentOS 8).

> Something strange seems to be going on, as I use centos 8 stream and here perl
> depends on Unicode::Normalize:
> 
> $ rpm -q --requires perl | grep Unicode-Normalize
> perl-Unicode-Normalize

In my CentOS 8-stream installation:

  $ rpm -q --requires perl
  package perl is not installed
  $ rpm -q --requires perl-interpreter | grep Unicode
  perl(Unicode::Normalize)

Apparently there is a smaller package than 'perl', called 'perl-interpreter',
and this is the one that I have installed. And this package depends on
perl-Unicode-Normalize but not one perl-Unicode-Collate. Why? Probably
because of the size: perl-Unicode-Normalize is 1 MB large, perl-Unicode-Collate
weighs 5 MB.

> Without Unicode::Collate the issue is not only that the test suite does
> not pass, but also texi2any will fail in any case.

Then the right thing is a configure test, that aborts the configuration
with a message like "Your perl installations lacks the Unicode::Collate module.
If you are on a Red Hat distribution, try installing the perl-Unicode-Collate
package."

Bruno

Re: Texinfo 7.0.90 pretest on CentOS 8-stream (Unicode::Collate)

[Bruno Haible]

Gavin Smith wrote:
> As the log file shows, the Unicode::Collate module is not found.

Indeed: just running perl with a 1-line input

  $ perl
  use Unicode::Collate;

produces an error on CentOS 8-stream, but not e.g. on Ubuntu.

When I manually search for it in @INC, I don't see it installed:

  $ for d in <@INC as printed by 'perl -V'>; do
  find $d/ -name '*Collate*'
done

prints nothing about *Unicode/Collate* in CentOS 8-stream, where it prints
e.g. /usr/lib/x86_64-linux-gnu/perl/5.34/Unicode/Collate.pm
 /usr/share/perl/5.34/Unicode/Collate
on Ubuntu.

> You can also run "corelist -a Unicode::Collate" to confirm it is a core
> module.

Yes, according to this command, Unicode::Collate version 1.19 should be
present.

> It's possible that a distribution does something to install fewer packages,

The packaging source code for this module is here:
https://git.centos.org/rpms/perl/blob/c8s/f/SPECS/perl.spec
lines 2816..2832. Apparently they intended Unicode::Collate to be packaged
as a separate dnf package.

And indeed,

$ dnf list | grep perl | grep -i unicode

list both perl-Unicode-Normalize and perl-Unicode-Collate as available.

But

$ dnf list installed | grep perl | grep -i unicode

shows that perl-Unicode-Normalize is installed, but perl-Unicode-Collate is not.

> Is it possible that Unicode::Collate is installed on the system somewhere
> but that we aren't finding it due to incorrect @INC?

No.
  $ find /usr -name Collate.pm
finds I18N/Collate.pm but no Unicode/Collate.pm.

> Or is there any reason why Unicode::Collate wouldn't be installed?  Was
> Perl installed in an unusual way on this system?

No.

For comparison, here are the results for older CentOS distributions:
  - CentOS 8: The same 52 test failures.
  - CentOS 7: "make check" passes.
  - CentOS 6: "make check" passes.

> I don't know what the solution to this is.

You could, at configure time, test what's the exit code of 'perl' when
run with 1-line input:
  use Unicode::Collate;

Bruno

Re: ISO C99 mixed declaration and statements

[Bruno Haible]

Gavin Smith wrote:
> It may have been some MS-Windows compiler (MSVC?) that didn't support it,

Yes, I too have some recollection of MSVC (9 perhaps?) not supporting it.
But since MSVC 14 (released in 2015) there is no problem any more.

> I am going to take out the recommendation that we check for this with
> compiler warnings as this would simplify things.

Not only it simplifies things. It also makes it easier to reduce the
scope of local variables, which makes the code easier to read. Take
this patch, for example:
https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=1ea34cbf6a235f2436a3265ab9ded6f04748051e

Bruno

ISO C99 mixed declaration and statements

[Bruno Haible]

Hi Gavin,

I see this commit:
* install-info/install-info.c (output_dirfile): Avoid mixed
declaration and statements.

Is it possible nowadays to assume ISO C99 mixed declaration and statements
are supported by the C compiler? I don't know about the portability targets
of TeXinfo, but for those of Gnulib, documented in [1], we can now make
this assumption [2].

In Gnulib, for more than one year, we use Autoconf's AC_PROG_CC macro to ensure
an option to enable C99 mode (or newer) is used if available, and we use
declarations after statements more and more. This works just fine. The last
compiler that I had access to, that did not grok declarations after statements,
was 'cc' on IRIX 6.5. So I used gcc on that platform.

Bruno

[1] https://www.gnu.org/software/gnulib/manual/html_node/Target-Platforms.html
[2] 
https://www.gnu.org/software/gnulib/manual/html_node/C99-features-assumed.html

Re: Texinfo 7.0.90 pretest on mingw

[Bruno Haible]

Eli Zaretskii wrote:
> > On mingw 5.0.3, I see 56 test failures:
> > 
> > FAIL: ii-0001-test
> > FAIL: ii-0002-test
> 
> Isn't this a problem with different EOL conventions in the expected
> results and in what install-info compiled for Windows produces?

That was the problem last time [1]. Meanwhile, Gavin Smith has
incorporated your trick to invoke 'diff --strip-trailing-cr'.
And now, the test suite shows a real bug. Look into the test-suite.log
that I have attached. [2]

Bruno

[1] https://lists.gnu.org/archive/html/bug-texinfo/2022-10/msg00213.html
[2] https://lists.gnu.org/archive/html/bug-texinfo/2023-08/txt3jqUsF3qnL.txt

Re: Texinfo 7.0.90 pretest on CentOS 8-stream

[Bruno Haible]

Find attached the mail body (body.txt), log file (tp/tests/test-suite.log),
and some info (info.txt), which I can't include in the mail body if I want
this mail to pass the spam filters.

Bruno



attachments.tar.xz
Description: application/xz-compressed-tar

Re: Texinfo 7.0.90 pretest on other platforms

[Bruno Haible]

The build succeeds and "make check" passes on
- Linux: Debian 9.1, Debian 12, OpenSUSE Leap 15.5, Manjaro 17, Alpine Linux 
3.14
- GNU/Hurd
- macOS 12.5
- FreeBSD 13.2
- NetBSD 9.0
- OpenBSD 7.2
- Solaris 11.4
- Cygwin 2.9.0

Bruno

Re: Texinfo 7.0.90 pretest on mingw

[Bruno Haible]

On mingw 5.0.3, I see 56 test failures:

FAIL: ii-0001-test
FAIL: ii-0002-test
FAIL: ii-0003-test
FAIL: ii-0004-test
FAIL: ii-0005-test
FAIL: ii-0006-test
FAIL: ii-0007-test
FAIL: ii-0008-test
FAIL: ii-0009-test
FAIL: ii-0010-test
FAIL: ii-0011-test
FAIL: ii-0012-test
FAIL: ii-0014-test
FAIL: ii-0015-test
FAIL: ii-0017-test
FAIL: ii-0018-test
FAIL: ii-0019-test
FAIL: ii-0020-test
FAIL: ii-0021-test
FAIL: ii-0022-test
FAIL: ii-0023-test
FAIL: ii-0024-test
FAIL: ii-0025-test
FAIL: ii-0026-test
FAIL: ii-0027-test
FAIL: ii-0028-test
FAIL: ii-0029-test
FAIL: ii-0030-test
FAIL: ii-0031-test
FAIL: ii-0032-test
FAIL: ii-0033-test
FAIL: ii-0034-test
FAIL: ii-0035-test
FAIL: ii-0036-test
FAIL: ii-0037-test
FAIL: ii-0038-test
FAIL: ii-0039-test
FAIL: ii-0040-test
FAIL: ii-0041-test
FAIL: ii-0042-test
FAIL: ii-0043-test
FAIL: ii-0044-test
FAIL: ii-0045-test
FAIL: ii-0046-test
FAIL: ii-0047-test
FAIL: ii-0048-test
FAIL: ii-0050-test
FAIL: ii-0051-test
FAIL: ii-0052-test
FAIL: ii-0053-test
FAIL: ii-0054-test
FAIL: ii-0055-test
FAIL: ii-0056-test
FAIL: ii-0057-test
FAIL: ii-0058-test
FAIL: ii-0059-test

Find attached the log file.

It looks similar to my report regarding AIX 7.3, despite the error message being
"Permission denied" rather than "Cross-device link".

Bruno
===
   GNU Texinfo 7.0.90: install-info/tests/test-suite.log
===

# TOTAL: 59
# PASS:  3
# SKIP:  0
# XFAIL: 0
# FAIL:  56
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: ii-0001-test
==

+ . ./defs
++ SHELL=/bin/sh
++ export SHELL
++ CDPATH=
++ unset CDPATH
++ test '!' -f ./defs
++ test -z ../../../install-info/tests
++ LC_ALL=C
++ export LC_ALL
++ valgrind=
++ top_builddir=../..
++ install_info=../../install-info/ginstall-info
++ export install_info
++ top_srcdir=../../..
++ testdir=../../../install-info/tests
++ export testdir
++ test -z ''
++ TMPDIR=/tmp
++ export TMPDIR
++ : grep -E
++ test -n 'C:\WINDOWS\system32\cmd.exe'
++ uname
++ grep -E -iv 'cygwin|mingw|djgpp'
++ path_sep=:
++ diff=diff
++ echo mingw32
++ grep -E mingw
++ diff='diff --strip-trailing-cr'
++ findprog mktemp
++ local 'saveIFS= 	
'
++ IFS=:
++ for dir in $PATH
++ IFS=' 	
'
++ test -f /usr/local/mingw64/bin/mktemp
++ test -f /usr/local/mingw64/bin/mktemp.exe
++ for dir in $PATH
++ IFS=' 	
'
++ test -f /usr/x86_64-w64-mingw32/sys-root/mingw/bin/mktemp
++ test -f /usr/x86_64-w64-mingw32/sys-root/mingw/bin/mktemp.exe
++ for dir in $PATH
++ IFS=' 	
'
++ test -f /usr/local/bin/mktemp
++ test -f /usr/local/bin/mktemp.exe
++ for dir in $PATH
++ IFS=' 	
'
++ test -f /usr/bin/mktemp
++ test -x /usr/bin/mktemp
++ return 0
++ :
++ mktemp ii01-
+ outputdirfile=ii01-Ea2AdSTr
+ cp ../../../install-info/tests/ii-0001-input-dir-file ii01-Ea2AdSTr
+ '[' x0 '!=' x0 ']'
+ ../../install-info/ginstall-info ../../../install-info/tests/ii-0001-input-info-file ii01-Ea2AdSTr
ii01-Ea2AdSTr: Permission denied
+ retval=0
+ '[' x0 '!=' x0 ']'
+ diff --strip-trailing-cr ../../../install-info/tests/ii-0001-expected-dir-file ii01-Ea2AdSTr
24d23
< * Gnu: (gnu).   Wildebeest native to Africa.
+ retval=1
+ rm -f ii01-Ea2AdSTr
+ exit 1
FAIL ii-0001-test (exit status: 1)

FAIL: ii-0002-test
==

+ . ./defs
++ SHELL=/bin/sh
++ export SHELL
++ CDPATH=
++ unset CDPATH
++ test '!' -f ./defs
++ test -z ../../../install-info/tests
++ LC_ALL=C
++ export LC_ALL
++ valgrind=
++ top_builddir=../..
++ install_info=../../install-info/ginstall-info
++ export install_info
++ top_srcdir=../../..
++ testdir=../../../install-info/tests
++ export testdir
++ test -z ''
++ TMPDIR=/tmp
++ export TMPDIR
++ : grep -E
++ test -n 'C:\WINDOWS\system32\cmd.exe'
++ uname
++ grep -E -iv 'cygwin|mingw|djgpp'
++ path_sep=:
++ diff=diff
++ echo mingw32
++ grep -E mingw
++ diff='diff --strip-trailing-cr'
++ findprog mktemp
++ local 'saveIFS= 	
'
++ IFS=:
++ for dir in $PATH
++ IFS=' 	
'
++ test -f /usr/local/mingw64/bin/mktemp
++ test -f /usr/local/mingw64/bin/mktemp.exe
++ for dir in $PATH
++ IFS=' 	
'
++ test -f /usr/x86_64-w64-mingw32/sys-root/mingw/bin/mktemp
++ test -f /usr/x86_64-w64-mingw32/sys-root/mingw/bin/mktemp.exe
++ for dir in $PATH
++ IFS=' 	
'
++ test -f /usr/local/bin/mktemp
++ test -f /usr/local/bin/mktemp.exe
++ for dir in $PATH
++ IFS=' 	
'
++ test -f /usr/bin/mktemp
++ test -x /usr/bin/mktemp
++ return 0
++ :
++ mktemp ii02-
+ outputdirfile=ii02-ClJdm6lh
+ cp ../../../install-info/tests/ii-0002-input-dir-file ii02-ClJdm6lh
+ '[' x0 '!=' x0 ']'
+ ../../install-info/ginstall-info ../../../install-info/tests/ii-0002-input-info-file ii02-ClJdm6lh
ii02-ClJdm6lh: Permission denied
+ retval=0
+ '[' x0 '!=' x0 ']'
+ diff --strip-trailing-cr ../../../install-info/tests/ii-0002-expected-dir-file ii02-ClJdm6lh
24,25d23
< * Gnu: (gnu).   Wildebeest native to Africa.
< * Wildebeest: (gnu).Wildebeest native to Africa.
+ retval=1
+ rm -f 

Re: Texinfo 7.0.90 pretest on AIX 7.3

[Bruno Haible]

On AIX 7.3.1, the build succeeds (with ibm-clang), but there are 58 test
failures:

FAIL: ii-0001-test
FAIL: ii-0002-test
FAIL: ii-0003-test
FAIL: ii-0004-test
FAIL: ii-0005-test
FAIL: ii-0006-test
FAIL: ii-0007-test
FAIL: ii-0008-test
FAIL: ii-0009-test
FAIL: ii-0010-test
FAIL: ii-0011-test
FAIL: ii-0012-test
FAIL: ii-0013-test
FAIL: ii-0014-test
FAIL: ii-0015-test
FAIL: ii-0017-test
FAIL: ii-0018-test
FAIL: ii-0019-test
FAIL: ii-0020-test
FAIL: ii-0021-test
FAIL: ii-0022-test
FAIL: ii-0023-test
FAIL: ii-0024-test
FAIL: ii-0025-test
FAIL: ii-0026-test
FAIL: ii-0027-test
FAIL: ii-0028-test
FAIL: ii-0029-test
FAIL: ii-0030-test
FAIL: ii-0031-test
FAIL: ii-0032-test
FAIL: ii-0033-test
FAIL: ii-0034-test
FAIL: ii-0035-test
FAIL: ii-0036-test
FAIL: ii-0037-test
FAIL: ii-0038-test
FAIL: ii-0039-test
FAIL: ii-0040-test
FAIL: ii-0041-test
FAIL: ii-0042-test
FAIL: ii-0043-test
FAIL: ii-0044-test
FAIL: ii-0045-test
FAIL: ii-0046-test
FAIL: ii-0047-test
FAIL: ii-0048-test
FAIL: ii-0049-test
FAIL: ii-0050-test
FAIL: ii-0051-test
FAIL: ii-0052-test
FAIL: ii-0053-test
FAIL: ii-0054-test
FAIL: ii-0055-test
FAIL: ii-0056-test
FAIL: ii-0057-test
FAIL: ii-0058-test
FAIL: ii-0059-test

These test failures indicate that the built 'install-info' program is usually
non-functional.

The first failure, from install-info/tests/test-suite.log :

FAIL: ii-0001-test
==

+ . ./defs
+ SHELL=/bin/sh
+ export SHELL
+ CDPATH=
+ unset CDPATH
+ test ! -f ./defs
+ test -z ../../../install-info/tests
+ LC_ALL=C
+ export LC_ALL
+ valgrind=
+ top_builddir=../..
+ install_info=../../install-info/ginstall-info
+ export install_info
+ top_srcdir=../../..
+ testdir=../../../install-info/tests
+ export testdir
+ test -z /tmp
+ : grep -E
+ test -n 
+ path_sep=:
+ diff=diff
+ echo aix7.3.1.0
+ grep -E mingw
+ 1> /dev/null
+ findprog mktemp
+ + mktemp ii01-
outputdirfile=/tmp/iimktemp22610250-10948/ii01-
+ cp ../../../install-info/tests/ii-0001-input-dir-file 
/tmp/iimktemp22610250-10948/ii01-
+ [ x0 != x0 ]
+ ../../install-info/ginstall-info 
../../../install-info/tests/ii-0001-input-info-file 
/tmp/iimktemp22610250-10948/ii01-
infodirD4sMea: Cross-device link
+ retval=0
+ [ x0 != x0 ]
+ diff ../../../install-info/tests/ii-0001-expected-dir-file 
/tmp/iimktemp22610250-10948/ii01-
diff: /tmp/iimktemp22610250-10948/ii01-: No such file or directory
+ retval=2
+ rm -f /tmp/iimktemp22610250-10948/ii01-
+ exit 2
FAIL ii-0001-test (exit status: 2)

I can reproduce the failure:

$ cd install-info
$ mkdir /tmp/iimk1
$ cp ../../install-info/tests/ii-0001-input-dir-file /tmp/iimk1/ii01
$ ls -l /tmp/iimk1/ii01
-rw-r--r--1 haible   usr 739 Aug 17 21:21 /tmp/iimk1/ii01
$ ./ginstall-info ../../install-info/tests/ii-0001-input-info-file 
/tmp/iimk1/ii01
infodirPFiMea: Cannot link to a file on another device.
$ echo $?
0

* Why is the error message "Cross-device link" in the tests but
"Cannot link to a file on another device." in my experiment?
=> That's because of the locale. With LC_ALL=C the error message is
   "Cross-device link"; with LC_ALL=en_US it is
   "Cannot link to a file on another device."

* What's the 'truss' log?

$ LC_ALL=C truss ./ginstall-info 
../../install-info/tests/ii-0001-input-info-file /tmp/iimk1/ii01
execve("./ginstall-info", 0x2FF22A64, 0x20016CB8)  argc: 3
kusla(6, 0x09FFF0001170)= 0
read_sysconfig(0x09001000A00092C0, 0x0018, 0x0079, 
0x0071, 0x08FFF0D0, 0x0091, 0x0089, 
0x00B1) = 0x
sbrk(0x)= 0x000110001A98
vmgetinfo(0x0FFFEEC0, 7, 16)= 0
sbrk(0x)= 0x000110001A98
sbrk(0x0008)= 0x000110001A98
__libc_sbrk(0x00010020) = 0x000110001AA0
checkpnt_block(0x, 17)  = 0
checkpnt_block(0x, 17)  = 0
checkpnt_block(0x, 18)  = 0
checkpnt_block(0x, 18)  = 0
thread_init(0x096A28E0, 0x09001000A01CCF98) = 
sbrk(0x)= 0x000110011AC0
vmgetinfo(0x0528, 7, 16)= 0
smcr_procattr(0, 1, 0x0520) = 0
_getpid()   = 19071398
appulimit(1005, 0)  = 0x0E00
_thread_self()  = 44433791
thread_setmystate(0x, 0x0060) = 0
thread_setmystate(0x0FFFEC80, 0x0008) = 0
_sigaction(3, 0x0420, 0x0450) = 0
_sigaction(4, 0x0420, 0x0450) = 0
_sigaction(5, 0x0420, 0x0450) = 0
_sigaction(6, 0x0420, 0x0450) = 0
_sigaction(7, 0x0420, 0x0450) = 0

Re: Take account of splitting option in gendocs.sh

[Bruno Haible]

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
applied your patch.

Bruno

Re: makeinfo no longer validates the menu structure

[Bruno Haible]

Patrice Dumas wrote:
> It is on purpose that CHECK_NORMAL_MENU_STRUCTURE is needed, because
> with manually made menus and node directions, it is not really possible
> to be sure that an irregular structure is not done on purpose.

Are you serious about that? Reading an info file should not be an experience
like an adventure game, where each cave has an unknown number of hidden
entrances, or where you can leave a room through the EAST exit and enter
the next one through the SOUTH door.

> Setting
> customization variable is not done with environment variables but with
> the -c option.  With that option, for your reproducer, I get (with the
> texinfo git head version):
> 
> ~/tmp/gnulib/doc((HEAD detached at 458694e417))$ env LANG= LC_MESSAGES= 
> LC_ALL= LANGUAGE= ~/src/texinfo/tp/texi2any.pl -c 
> CHECK_NORMAL_MENU_STRUCTURE=1  --no-split --reference-limit=2000 gnulib.texi
> strings.texi:208: warning: node next pointer for `Strings with NUL 
> characters' is `String Functions in C Locale' but next is `Comparison of 
> string APIs' in menu
> strings.texi:21: warning: node `Strings' lacks menu item for `String 
> Functions in C Locale' despite being its Up target
> strings.texi:233: warning: node prev pointer for `Comparison of string APIs' 
> is `String Functions in C Locale' but prev is `Strings with NUL characters' 
> in menu

The essential warning in this case is the second one. The other two are
confusing, because they don't point at the root cause.

It's good that it's still possible to get this warning. But for my feeling
it's way too hidden behind the bars of customization variables.

How about adding an option '--validate' to makeinfo? Its effect - at least
in 'info' mode - should be to enable this CHECK_NORMAL_MENU_STRUCTURE variable.

Bruno

makeinfo no longer validates the menu structure

[Bruno Haible]

Hi,

In .info files, the @menu items are essential for a good navigation
experience. Thus, it is helpful if 'makeinfo' reports

  ./strings.texi:21: node `Strings' lacks menu item for `String Functions in C 
Locale' despite being its Up target

makeinfo did so up to version 6.7. In versions 6.8 and 7.0.3, it does not
do that any more.

How to reproduce:

$ cd /tmp
$ git clone git://git.savannah.gnu.org/gnulib.git
$ cd gnulib
$ git checkout 458694e4174ea60b525e688f8d9ec4950f85b4ab
$ cd doc
$ make updated-stamp
$ env LANG= LC_MESSAGES= LC_ALL= LANGUAGE= makeinfo --no-split 
--reference-limit=2000 gnulib.texi

Result with makeinfo 6.4 ... 6.7:

./strings.texi:208: warning: node next `Strings with NUL characters' in menu 
`Comparison of string APIs' and in sectioning `String Functions in C Locale' 
differ
./c-locale.texi:1: warning: node `Comparison of string APIs' is next for 
`String Functions in C Locale' in sectioning but not in menu
./c-locale.texi:1: warning: node `Strings with NUL characters' is prev for 
`String Functions in C Locale' in sectioning but not in menu
./c-locale.texi:1: warning: node `Strings' is up for `String Functions in C 
Locale' in sectioning but not in menu
./strings.texi:21: node `Strings' lacks menu item for `String Functions in C 
Locale' despite being its Up target
./strings.texi:233: warning: node prev `Comparison of string APIs' in menu 
`Strings with NUL characters' and in sectioning `String Functions in C Locale' 
differ

Result with makeinfo 6.8, 7.0.3:

No warning, no error, and the problem has not been autocorrected: The menu in
section "16.1 Strings" has 3 items; the section
"16.1.2 Strings with NUL characters" is missing in this menu.

To me, that's a regression, since I was relying on these diagnostics for 
producing
navigatable info files.

The documentation
https://www.gnu.org/software/texinfo/manual/texinfo/html_node/Invoking-texi2any.html
as well as "makeinfo --help" tell me about options
  --no-validate
  --no-warn
but don't give me hints how to enforce validation of menu structure.

The texinfo 6.8 announcement

mentions that 
"only check menu structure if CHECK_NORMAL_MENU_STRUCTURE variable is set"
but that does not have an effect, neither with 6.8 nor 7.0.3:

$ env CHECK_NORMAL_MENU_STRUCTURE=1 LANG= LC_MESSAGES= LC_ALL= LANGUAGE= 
makeinfo --no-split --reference-limit=2000 gnulib.texi
(Still no warning, no error.)

How to enable the validation of menu structure with makeinfo 6.8 or 7.0.3 ?

Bruno

Re: Take account of splitting option in gendocs.sh

[Bruno Haible]

Gavin Smith wrote:
> Here's an updated patch that does not affect the behaviour when
> used with texi2html.

Thanks for the improvement.

Bruno

Re: Take account of splitting option in gendocs.sh

[Bruno Haible]

Gavin Smith wrote, re
:
> > 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?

I can't review it, because the interplay between the script and the template
is something I don't know about.

Also: What are the effects of the patch on the output, if no --split option
is being passed to gendocs.sh?

Can someone else please review it? Maybe Karl?

Bruno

Re: Take account of splitting option in gendocs.sh

[Bruno Haible]

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 relying on it.

A web search on www.gnu.org shows that the manuals of at least the following
packages still were generated using texi2html:
  anubis, auctex, autogen, cfengine, cflow, classpath, combine, complexity,
  cpio, freeimpi, freetalk, gama, gnats, gnu-pw-mgr, gnugo, gnuit, gnupod,
  hurd, indent, libcdio, libjit, oleo, plotutils, radius, sqltutor, tar.

That's definitely more than nobody.

Bruno

Re: info may stress-test the terminal emulator

[Bruno Haible]

Hi Gavin,

> There's no way for me to reproduce this.

Neither can I. The next time it occurs, I hope I'll think at launching gdb
immediately.

Thanks for listening anyways.

Bruno

Re: info may stress-test the terminal emulator

[Bruno Haible]

Andreas Schwab wrote:
> > Is there a way to fix/improve this erratic behaviour of the 'info' program,
> > please?
> 
> Are you sure it's not the terminal emulator erratically sending an
> endless stream of characters to the inferior?  The info program normally
> emits a BEL when it receives a character input it doesn't recognize.

That's a theoretically possible cause, indeed. Normally the terminal emulator
sends an endless stream of characters only if
  - some heavy object is lying on the keyboard, or
  - some key is stuck in depressed position.
Both wasn't the case here.

So, I would still think that some of the 'terminal_ring_bell ();' invocations
in info/session.c was being executed too often. But since I didn't attach
gdb to 'info' at that moment, I don't know where.

Bruno

info may stress-test the terminal emulator

[Bruno Haible]

Hi,

This is a bug report about the 'info' program (GNU texinfo 6.8).

In a terminal emulator, I ran 'info m4', searched for m4_provide_if, then
attempted to abort this search by pressing some of the characters ESC, Enter,
Ctrl-Q, repeatedly. (I can't remember which character sequence exactly.)
At this point 'info' began to spew several BEL characters per second, which
the terminal emulator turned into popups on the screen. This caused the
terminal emulator to hang, losing the state of all the open tabs.

While it is certainly a bug in the terminal emulator when it hangs [1],
it is a fact that this terminal emulator was running flawlessly for over
two months and only the 'info' session brought it to its knees.
I have the suspicion that the 'info' program was feeding an endless
sequence of BEL characters to the terminal, thereby putting too much
stress on it.

Is there a way to fix/improve this erratic behaviour of the 'info' program,
please?

Bruno

[1] https://bugs.kde.org/show_bug.cgi?id=465469

Re: VirtualBox tricks (was: texinfo-7.0.1 on OpenSolaris)

[Bruno Haible]

Gavin Smith wrote:
> somehow harder to get access to local files.
> 
> The solution appears to be to install something called the Guest Additions.

Alternatively, one can use 'scp' between the guest and the host (at
IPv4 address 10.0.2.2).

Bruno

Re: texinfo-7.0.1 on OpenSolaris

[Bruno Haible]

Gavin Smith wrote:
> I will be deleting the disk image as soon as this is finished due
> to the amount of space it takes up.  I will not be testing routinely
> on OpenIndiana using VirtualBox.

That's OK, as I will be routinely testing on Solaris OpenIndiana
when you ask.

> > After the system it set up, do
> >   $ sudo pkg install developer/gcc-11
> >   $ sudo pkg install system/header
> >   $ sudo pkg install developer/debug/gdb
> >   $ sudo pkg install editor/gnu-emacs
> > (See also https://pkg.openindiana.org/hipster/en/index.shtml .)
> > Then you can build various GNU packages, as usual.
> 
> sudo wasn't a command but I got a root shell with "su".  I am
> using the image "OI-hipster-minimal-20221123.iso".

I was using the image OI-hipster-gui-20221123.iso. Small variations
like this, in the install experience, are to be expected.

> info runs "man -w FiLe-M" and find it was
> successful, with exit status 0, even though it prints errors:
> 
> man: /usr/share/man/whatis.tmp: Permission denied
> man: /usr/gnu/share/man/whatis.tmp: Permission denied
> 
> The man page for man on this virtual system says that -w updates
> the whatis database.
> 
> Changing the check in check_manpage_node to use "man --where" instead
> of "man -w" makes the test pass.  "man --where" has a non-zero exit
> status.

By doing this, you improved things on Solaris OpenIndiana. But it
got worse on FreeBSD, where the 'man' command has a '-w' option
that displays the location but does not have a '--where' option [1].
Likewise on macOS, where 'man --path' is an alias for 'man -w'.

How about, instead, reverting to option '-w' and disabling this
piece of code on Solaris (#ifndef __sun) ?

Bruno

[1] https://www.freebsd.org/cgi/man.cgi?query=man

Re: texinfo-7.0.1 on OpenSolaris (was: texinfo-6.8.90 pretest on OpenSolaris)

[Bruno Haible]

Building GNU texinfo 7.0.1 on OpenSolaris 2022.10, I get the same failure
as reported in
  :

FAIL: t/dir-file-sloppily.sh

Gavin Smith wrote:
> I don't know what is causing this and would need access to a system with
> either of those OS's installed to investigate further.

It is straightforward to install in VirtualBox, using a download from
https://www.openindiana.org/download/ .
Just make sure to allocate
  - at least 15 GB for the disk,
  - at least 3 GB of RAM.

After the system it set up, do
  $ sudo pkg install developer/gcc-11
  $ sudo pkg install system/header
  $ sudo pkg install developer/debug/gdb
  $ sudo pkg install editor/gnu-emacs
(See also https://pkg.openindiana.org/hipster/en/index.shtml .)
Then you can build various GNU packages, as usual.

Bruno

Re: namespacing issues with Gnulib

[Bruno Haible]

Eli Zaretskii wrote:
> > Attempting to --whole-archive link on that platform grants us:
> > 
> > $ x86_64-linux-musl-gcc -o ginstall-info install-info.o \
> >   -Wl,--whole-archive ../gnulib/lib/libgnu.a -Wl,--no-whole-archive
> > /usr/libexec/gcc/x86_64-linux-musl/ld: 
> > ../gnulib/lib/libgnu.a(libgnu_a-error.o): in function `error':
> > error.c:(.text+0xe0): multiple definition of `error'; 
> > install-info.o:install-info.c:(.text+0x4a0): first defined here
> > collect2: error: ld returned 1 exit status
> 
> Now _that_ IMO is a problem with Gnulib's use in this case: Gnulib
> evidently assumes that no application will define its own 'error'
> function, something that applications are free to do.
> ...
> In general, I believe certain names used by a Standard C Library are
> "reserved", and applications must not redefine them.  But 'error' is
> not one of those reserved names, AFAIK.  So an application is in its
> full rights when it defines its own 'error' that is not compatible
> with that from libc.

The standards make namespacing statements only w.r.t. the libc vs. the
application. From the point of view of the standards, install-info.c and
the Gnulib code are both on the application side; therefore the standards
cannot help resolving a conflict between install-info.c and Gnulib code.

What are the possible ways to resolve the conflict?

(A) Could Gnulib define the symbol 'error' as weak?

The concept of "weak" symbols exists only in ELF; therefore this
approach would be non-portable (not working with Windows DLLs or
COFF or MachO binary formats).

(B) An ad-hoc solution: Near the top of install-info.c, add
  #define error glibc_compatible_error
and later, after all #includes:
  #undef error

This is ugly, but it is cheap. And it does not cause problems if
install-info.c is split into several .c files in the future.

(C) gnulib-tool could infer from the command-line arguments that the
module 'error' is only indirectly used, i.e. not explicitly requested,
and then arrange for the gnulib-lib subdirectory to have a config.h
that does

   #include "../config.h"/* include definitions from autoconf */
   /* put indirectly used symbols into a namespace */
   #define error libgnu_error

This approach is more generic, but
  - It is not (yet) implemented in gnulib-tool.
  - "make" will compile most Gnulib-derived object files twice, once
to detect which symbols to redefine in config.h, and once for real.

So, with this approach, the build times of your package are increased.

Any other ideas?

Bruno

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

[Bruno Haible]

Gavin Smith wrote:
> I expect it is not a gnulib problem.  install-info/install-info.c declares
> a function called "error" which appears to clash with a function from glibc.
> ... The "error" module is brought in by "xalloc" (which we
> ask for explicitly).

Yes, I think the problems already exists without use of Gnulib, as it's
a conflict between install-info.c and glibc. But with the Gnulib 'error'
module, the problem becomes bigger.

Namely, see:

$ nm --dynamic /lib/x86_64-linux-gnu/libc.so.6 | grep ' error'
001214e0 W error@@GLIBC_2.2.5
00121700 W error_at_line@@GLIBC_2.2.5
00221484 B error_message_count@@GLIBC_2.2.5
00221480 B error_one_per_line@@GLIBC_2.2.5
00221488 B error_print_progname@@GLIBC_2.2.5

glibc exports 'error' as a weak symbol. This means, without use of Gnulib,
the symbol from install-info.c overrides the one from glibc, and there is
a problem if and only if the 'install-info' program links dynamically
(or loads via 'dlopen') a shared library which happens to use error()
and expects the semantics from glibc.

Whereas with the Gnulib 'error' module, there is a conflict between the
two global function definitions (with 'T' linkage) in install-info.c and
in error.c *always*.

> The simplest way to fix this problem would probably be to rename the "error"
> function in install-info.c.

Yes, or make it 'static' (like Arsen suggested).

Bruno

Re: Texinfo translation error, texinfo_document domain

[Bruno Haible]

Patrice Dumas wrote:
> Beware that this has changed in the forthcoming release in which UTF-8
> is considered as preferred.

Cool!

> > 3) "For maximum portability of Texinfo documents across the many different 
> > user
> > environments in the world, we recommend sticking to 7-bit ASCII in the 
> > input"
> > Is this recommendation still relevant (in view of the Japanese and Chinese 
> > support)?
> 
> This has been removed already.

Cool again!

With this, most of the confusion should be gone. Thanks!!

Bruno

Re: Texinfo translation error, texinfo_document domain

[Bruno Haible]

Hi Patrice,

Patrice Dumas wrote:
> > My complaint was only about the (apparent / confused) need to use TeXinfo
> > syntax *for non-ASCII characters*.
> 
> It should only be required for non-ASCII characters if the encoding of the
> po file is us-ascii, for example in pt_BR.us-ascii.po the @-commands for
> accents need to be used.
> 
> In other cases, I think that it is best to leave it to the translators.
> They can use @-commands if they wish, and not use them if they don't
> want to, both for accented letters and, more generally, for styling.
> 
> This is explainined in
> https://www.gnu.org/software/texinfo/manual/texinfo/html_node/Internationalization-of-Document-Strings.html
> 
> (though upon reading it I realized that it is a bit out of date...).

In this documentation page
  
https://www.gnu.org/software/texinfo/manual/texinfo/html_node/Internationalization-of-Document-Strings.html
some importance is given to the @documentencoding.

The @documentencoding is documented in
  
https://www.gnu.org/software/texinfo/manual/texinfo/html_node/_0040documentencoding.html
The way I read this page, it recommends to use '@documentencoding US-ASCII'
when possible.

When I combine this with what you wrote above, the recommendation is
  - to use the US-ASCII encoding for the texinfo_document domain PO files,
  - to use the @-commands for the non-ASCII characters in these PO files.

This is what would have been expected in the year 2000. But meanwhile UTF-8
support is wide-spread in so many tools, editors, and viewers.

And in texinfo/doc/short-sample-{ja,zh}.texi you have examples with Japanese
and Chinese text and fonts, both happily using UTF-8 for input.

This leaves me confused.

Can we remove the obstacles that (apparently) discourage Japanese, Chinese,
Hindi translators from producing PO files for the texinfo_document domain?
Gavin observed that many translation teams are not very active. True. But if
you give them enough years of time, and if the usual tools & procedures are
supported, they will some day do the translations.

1) 
https://www.gnu.org/software/texinfo/manual/texinfo/html_node/_0040documentencoding.html
talks about the 'coding:' marker in Info files. Is it a problem to have an info 
file
with 'coding: UTF-8' nowadays? If users are in an old-style ISO-8859-1 locale, 
then
the 'info' program will hopefully convert the contents to ISO-8859-1 on-the-fly 
for
display (like it surely does in the opposite case, when viewing an info file 
with
'coding: ISO-8859-1' in an UTF-8 locale)?

2) 
https://www.gnu.org/software/texinfo/manual/texinfo/html_node/_0040documentencoding.html
also says "in Info and plain text output ... accent constructs and special 
characters
... are output as the actual 8-bit or UTF-8 character in the given encoding 
where possible."
Is this a problem? Nowadays, UTF-8 is the standard encoding for text files. It's
ISO-8859-1 encoded files which sometimes display in a weird way.

3) "For maximum portability of Texinfo documents across the many different user
environments in the world, we recommend sticking to 7-bit ASCII in the input"
Is this recommendation still relevant (in view of the Japanese and Chinese 
support)?

4) 
https://www.gnu.org/software/texinfo/manual/texinfo/html_node/Internationalization-of-Document-Strings.html
Why is the @documentencoding relevant here? Why can't TeXinfo just recode things
as needed?
I guess that if @documentencoding were made to be irrelevant here, then above
you would not need to say
  "for example in pt_BR.us-ascii.po the @-commands for accents need to be used."
since there would be only one pt_BR.po, and translations would pick UTF-8 for 
its
encoding, like they do for so many other translation domains.

Bruno

Re: Avoid gnulib redefinitions - MDA

[Bruno Haible]

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 decline all corrections done by Gnulib.
These are documented in the manual. For example, for 'fdopen' [1]
we have documented

  Portability problems fixed by Gnulib:

This function crashes when invoked with invalid arguments on
some platforms: MSVC 14.
On Windows platforms (excluding Cygwin), this function does not
set errno upon failure. 

So, if you always use fdopen() with correct arguments and if, in
case of a NULL return of this function, the code does not look at
errno, then the '#undef fdopen' is OK. (On those platforms where
the Microsoft deprecated alias still work, or when it is overridden
by a redirect to some perl internal function.)

Bruno

[1] https://www.gnu.org/software/gnulib/manual/html_node/fdopen.html

Re: [platform-testers] texinfo-6.8.91 pretest

[Bruno Haible]

Gavin Smith wrote:
> https://alpha.gnu.org/gnu/texinfo/texinfo-6.8.91.tar.xz

The build succeeds and all tests pass on:

  * various Linux distros with glibc
(Ubuntu 22.04, Debian 9.1, Debian 11.1, CentOS 8-stream, OpenSUSE Leap 15.2,
Manjaro 17)
  * GNU/Hurd (although 'info' wasn't built since I had not installed 'ncurses')
  * macOS 10.13
  * FreeBSD 13.1, NetBSD 9, OpenBSD 6.5
  * AIX 7.1
  * Solaris 11.4
  * Cygwin
  * mingw

> Problems reported since the last pretest that we weren't able to fix:
> 
> * Failure of info/t/dir-file-sloppily.pl on Solaris 11 OmniOS
>   and Solaris 11 OpenIndiana

I still see this test failure on these two platforms.

Bruno

Re: Avoid gnulib redefinitions - MDA

[Bruno Haible]

Hi Gavin,

> 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 that this didn't work when building on
> MS-Windows.  I found that it should maybe be GL_GNULIB_MDA_FDOPEN instead:
> 
> https://lists.gnu.org/archive/html/bug-texinfo/2022-10/msg00180.html
> 
> I had identified the following change as potentially being responsible:
> 
> 2021-04-11  Bruno Haible  
> 
> Support several gnulib-tool invocations under the same configure.ac.
> Reported by Reuben Thomas  in
> 
> <https://lists.gnu.org/archive/html/bug-gnulib/2021-04/msg00104.html>.  
> This is done by defining the Gnulib module indicator variables per
> gnulib-tool invocation. So that a generated .h file is no longer
> influenced by the set of modules used in other gnulib-tool 
> invocations. 
> * gnulib-tool (func_compute_include_guard_prefix): Set
> module_indicator_prefix.
> 
> 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
before April 2021, GL_GNULIB_MDA_FDOPEN=0 after April 2021) is an undocumented
functionality. It is not expected that it will break soon. The 2021-04-11
change that you cited above was a once-in-a-decade change. But it may break
theoretically, since it is not in the form of a stable functionality.
(A stable, supported functionality would be something like a gnulib-tool
option and/or a module name.)

> We don't use fdopen, putenv or mktemp in the library being built, but these
> are pulled in by Gnulib dependencies.
>
> I don't know if it is possible at all but it would seem to be better
> for Gnulib not to redefine symbols that are not actually used in the
> program.

I chose not to do so for the following reasons:

  * These "Microsoft deprecated aliases" are deprecated. This means, they
can break at any moment, causing bug reports regarding all released
tarballs. It is better (for 99% of the package maintainers) to have
this problem dealt with, in advance, _before_ it becomes an FTBFS.

  * Already now, these "Microsoft deprecated alias" symbols cause link
errors in a particular native Windows platform. Namely, when clang-cl
is used in combination with the MSVC header files. (clang for Windows
does not come with its own Win32 API header files, like mingw does.)

  * There are 50 "Microsoft deprecated aliases". If Gnulib would use an
opt-in approach for these, i.e. if the package maintainer would have
to enumerate all of these that their package uses one-by-one, it
would be too much maintenance effort / too high risk of mistake.

  * Given that in this list you find symbols like 'open' / 'creat' / 'close'
and 'strdup', most programs that rely on POSIX APIs need the
"Microsoft deprecated aliases" handling. Only programs that use only
ISO C APIs wouldn't care; but these programs usually don't need Gnulib
anyway.

So, to me, an opt-out approach seems to be the best approach here.

It broke because the hint that I gave you in March 2021 was not a stable API.
But we don't have stable APIs for everything.

Bruno

Re: texinfo-6.8.90 pretest on mingw

[Bruno Haible]

I had reported:
> On mingw (the 'w64' flavour, that can be installed with Cygwin 2.9.0)
> - the compilation succeeds,
> - there is 1 test failure for 'info',
> - nearly all of the 'ii--test' tests fail,
> - no test failures in tp/tests/.

Now, in texinfo-6.8.91, all tests pass (in the same environment).

Bruno

Re: texinfo-6.8.90 pretest on mingw

[Bruno Haible]

Gavin Smith wrote:
> On Sun, Oct 23, 2022 at 11:55:09AM +0100, Gavin Smith wrote:
> > There doesn't appear to be a similar option for 'grep'.  However,
> > since it is just the one test, we can easily work around the problem
> > by taking the '$' out - the test in question would still work properly.
> 
> Done in commit f71e8cf52b.

I confirm that in 6.8.91, in my mingw environment (Cygwin + mingw-w64), all
'info' tests pass.

Bruno

Re: texindex awk syntax error

[Bruno Haible]

Gavin Smith wrote:
> AC_PATH_PROGS_FEATURE_CHECK does the job

Nice one; thanks for the lesson.

> although it is slightly complicated to use:
> 
> AC_CACHE_CHECK([for awk], [ac_cv_path_TI_AWK],
> [AC_PATH_PROGS_FEATURE_CHECK([TI_AWK], [awk gawk mawk nawk],
>   [[$ac_path_TI_AWK 'function foo () {}' 2>/dev/null \
>&& ac_cv_path_TI_AWK=$ac_path_TI_AWK ac_path_TI_AWK_found=:]],
>   [AC_MSG_ERROR([awk not found])])])
> AC_SUBST([TI_AWK], [$ac_cv_path_TI_AWK])

I confirm that, as part of 6.8.91, it fixes the problem on Solaris 11.4.

Bruno

Re: macOS test failures - LC_ALL / LC_CTYPE / LC_MESSAGES

[Bruno Haible]

Gavin Smith wrote:
> I fixed this by changing LC_ALL to LC_MESSAGES in gdt, as that was
> the only locale category we needed to change.

I confirm that it's fixed in 6.8.91.

Bruno

Re: texinfo-6.8.90 pretest and BSD make

[Bruno Haible]

Gavin Smith wrote:
> >  Texinfo/Commands.pm: Texinfo/XS/parsetexi/command_data.txt
> > $(MKDIR_P) Texinfo
> > -   $(srcdir)/maintain/regenerate_commands_perl_info.pl < $<
> > +   $(srcdir)/maintain/regenerate_commands_perl_info.pl < 
> > $(srcdir)/Texinfo/XS/parsetexi/command_data.txt
> >  
> 
> Thanks, I had already found out about this and have made this change
> already.

Thanks. I confirm that it's fixed in 6.8.91.

Bruno

Re: Texinfo translation error, texinfo_document domain

[Bruno Haible]

Hi Gavin,

> > It sounds wrong to expect translators to use TeXinfo syntax for
> > non-ASCII characters, for three reasons:
> > 
> > 1) Translator tools support the common (state-free) charset encodings,
> >namely UTF-8, ISO-8859-*, and so on. Not TeX with \, not TeXinfo with
> >@, not ISO-2022-*. PO files that expect TeXinfo syntax deny translators
> >from the ability to use their native input methods.
> > 
> >I guess this is the reason why you don't see Chinese, Hindi, Vietnamese,
> >Armenian, etc. translations for texinfo/po_document/*.po.
> 
> UTF-8 is allowed and works.  See e.g. po_document/uk.po.

Good, that's better than I thought. Then, why are there no Chinese, Hindi,
etc. translations of this POT file? Karl [1] suggested that "there is
confusion in both directions among the translators". Maybe it's as simple
as sending a mail to these translation teams and clarifying to them that they
can submit normal UTF-8 PO files for this domain?

> > 2) Even for translators who are familiar with the TeXinfo syntax, the
> >TeXinfo syntax allows for mistakes like the one reported above, that
> >could not happen if UTF-8 was used for the encoding, in the translator's
> >workflow.
> 
> I remember supporting Texinfo in document strings was a significant
> complication as we had to parse the results.  However, it works fine now
> and would be hard to eliminate completely.

>From [1] is sounds like you see it as a feature that translators can
introduce their own markup, e.g. add @itemize where they find it useful.
Although this feature turns into a misfeature at the moment when the
maintenance of a PO file passes from one member of the translation team
to another.

> Currently there are some strings like
> 
> msgid "see {reference} in @cite{{book}}"
> 
> We'd have to work out if we could change it to
> 
> msgid "see {reference} in {book}"

msgid "see {reference} in @cite{{book}}"
is not a problem. Translators are used to preserving markup in the
translations, whether it be HTML, TeXinfo, or any other markup language.

No one is asking you to remove @cite and such from the msgids.

If there is enough demand, there could even be a syntax check in 'msgfmt'
for this kind of syntax (e.g. to verify that the translator has no
accidentally omitted some opening or closing brace).

My complaint was only about the (apparent / confused) need to use TeXinfo
syntax *for non-ASCII characters*.

Bruno

[1] https://lists.gnu.org/archive/html/texinfo-devel/2015-04/msg9.html

Re: Texinfo translation error, texinfo_document domain

[Bruno Haible]

Hi TeXinfo maintainers,

This exchange is from the French translators mailing list:

Jean-Charles Malahieude wrote:
> Le 28/10/2022 à 19:42, Gavin Smith a écrit :
> > In the translations for 'texinfo_document', fr.po:
> > 
> > [...]
> > #: tp/Texinfo/Transformations.pm:597
> > msgid " --- The Detailed Node Listing ---"
> > msgstr " --- Liste d@'etaill@'ee des n@oeuds ---"
> > 
> > I believe n@oeuds should be n@oe{}uds as otherwise there is an error
> > about an unknown command @oeuds.
> > 
> > I will not edit the file myself and wait for it to be updated.
> 
> New and corrected file uploaded to the FTP and accepted.
> 
> Cheers,
> --
> Jean-Charles

It sounds wrong to expect translators to use TeXinfo syntax for
non-ASCII characters, for three reasons:

1) Translator tools support the common (state-free) charset encodings,
   namely UTF-8, ISO-8859-*, and so on. Not TeX with \, not TeXinfo with
   @, not ISO-2022-*. PO files that expect TeXinfo syntax deny translators
   from the ability to use their native input methods.

   I guess this is the reason why you don't see Chinese, Hindi, Vietnamese,
   Armenian, etc. translations for texinfo/po_document/*.po.

2) Even for translators who are familiar with the TeXinfo syntax, the
   TeXinfo syntax allows for mistakes like the one reported above, that
   could not happen if UTF-8 was used for the encoding, in the translator's
   workflow.

3) This syntax reduces the functionality available in msgfmt. For example, in
   pt_BR.po there is the message

 #: tp/Texinfo/Convert/DocBook.pm:1088
 #, perl-brace-format
 msgid "see section ``{section_name}'' in @cite{{book}}"
 msgstr "veja se@,{c}@~{a}o ``{section_name}'' em @cite{{book}}"

   If this message was being checked by 'msgfmt -c', it would report an error,
   because the translation has more variables ({c}, {a}, {section_name},
   {book}) than the msgid. Thus I conclude that you have not enabled the '-c'
   option of msgfmt, and thus the — would-be useful — perl-brace-format
   argument checking does not happen.

I would strongly suggest to request UTF-8 encoded PO files from the
translators and convert them to TeXinfo syntax inside the TeXinfo build
system.

Bruno

Re: texindex awk syntax error

[Bruno Haible]

Eli Zaretskii wrote:
> > On the system that Bruno was testing, "awk" didn't work so "nawk" was
> > preferred.
> 
> So maybe we should verify that the "awk": we found satisfies our
> needs, and not just rely on the name?

Yes, that would be most in line with the Autoconf principles.

> E.g., we could see what "awk"
> outputs for "--version", and judge by that?

  $prog --version
does not help here, because nawk and mawk don't implement it. But what
works, is a test whether $prog supports the function syntax: On this
platform,

  gawk 'function foo () {}' 2>/dev/null
  nawk 'function foo () {}' 2>/dev/null

both have exit code 0, whereas

  awk 'function foo () {}' 2>/dev/null

has exit code 2.

To implement this, use a variant of AC_CHECK_PROGS that accepts a test
argument. (AM_PATH_PROG_WITH_TEST from gnulib/m4/progtest.m4 is not the
right there here, because it searches only for a single program name,
not multiple ones.)

Bruno

Re: texinfo-6.8.90 pretest on other platforms

[Bruno Haible]

It compiles fine, and all tests pass, on the following platforms:
  - various Linux systems (Ubuntu 22.04, Debian 9.1, Debian 11.1,
CentOS 8-stream, OpenSUSE Leap 15.2, Manjaro 17),
  - GNU/Hurd,
  - OpenBSD 6.5,
  - Cygwin 2.9.0.

Bruno

Re: texinfo-6.8.90 pretest on mingw

[Bruno Haible]

Gavin Smith wrote:
> I wonder if the 'ii--test' failures are related to ends-of-line too.

Yes, they are.

> Do any of the scripts produce output when run, e.g. ./ii-0001-test run
> from under install-info/tests/?

Yes, they produce output. The failure occurs e.g. in ii-0045-test because
diff's first argument has Unix newlines whereas its second argument has
 as line terminators.

Re: texinfo-6.8.90 pretest and BSD make

[Bruno Haible]

On NetBSD, with the default 'make' program, the build fails:

../../build-aux/install-sh -c -d Texinfo
sed -e 's|[@]USE_EXTERNAL_LIBINTL[@]|no|'  -e 
's|[@]USE_EXTERNAL_EASTASIANWIDTH[@]|no|'  -e 
's|[@]USE_EXTERNAL_UNIDECODE[@]|no|'  ../../tp/Texinfo/ModulePath.pm.in 
>Texinfo/ModulePath.pm
../../build-aux/install-sh -c -d Texinfo
../../tp/maintain/regenerate_commands_perl_info.pl < 
sh: 1: Syntax error: end of file unexpected
*** Error code 2

Stop.
make[3]: stopped in /home/bruno/texinfo-6.8.90/build/tp
*** Error code 1

The attached patch fixes it.

Bruno
--- tp/Makefile.am.bak	2022-10-11 17:00:52.0 +0200
+++ tp/Makefile.am	2022-10-22 23:41:29.988502422 +0200
@@ -325,7 +325,7 @@
 
 Texinfo/Commands.pm: Texinfo/XS/parsetexi/command_data.txt
 	$(MKDIR_P) Texinfo
-	$(srcdir)/maintain/regenerate_commands_perl_info.pl < $<
+	$(srcdir)/maintain/regenerate_commands_perl_info.pl < $(srcdir)/Texinfo/XS/parsetexi/command_data.txt
 
 libsrcdir = $(srcdir)/maintain/lib
 

Re: texinfo-6.8.90 pretest on Solaris 11.4

[Bruno Haible]

I reported:
> On Solaris 11.4, the compilation fails:
> 
> gcc -O2 -DHAVE_CONFIG_H -I. -I../../../gnulib/lib -I../..   
> -I/export/home/bruno/prefix64/include -Wall -D_REENTRANT  -Wno-cast-qual 
> -Wno-conversion -Wno-float-equal -Wno-sign-compare -Wno-undef 
> -Wno-unused-function -Wno-unused-parameter -Wno-float-conversion 
> -Wimplicit-fallthrough -Wno-pedantic -Wno-sign-conversion -Wno-type-limits 
> -Wno-unsuffixed-float-constants -g -O2 -MT libgnu_a-malloca.o -MD -MP -MF 
> .deps/libgnu_a-malloca.Tpo -c -o libgnu_a-malloca.o `test -f 'malloca.c' || 
> echo '../../../gnulib/lib/'`malloca.c
> ../../../gnulib/lib/malloca.c:42:56: error: macro "static_assert" requires 2 
> arguments, but only 1 given
>  static_assert (2 * sa_alignment_max - 1 <= (small_t) -1);
> ^
> ../../../gnulib/lib/malloca.c:42:1: warning: data definition has no type or 
> storage class
>  static_assert (2 * sa_alignment_max - 1 <= (small_t) -1);
>  ^
> ../../../gnulib/lib/malloca.c:42:1: warning: type defaults to ‘int’ in 
> declaration of ‘static_assert’ [-Wimplicit-int]
> gmake[4]: *** [Makefile:2521: libgnu_a-malloca.o] Error 1

This is now fixed in Gnulib.

Please update to the newest Gnulib.

Bruno

Re: macOS test failures - LC_ALL / LC_CTYPE / LC_MESSAGES

[Bruno Haible]

Gavin Smith wrote:
> When LC_ALL was restored
> (for the tests, this was to "C") this overrode a change to LC_CTYPE
> that had taken place elsewhere in the code, in the XS paragraph
> formatting module.  This broke iterating over UTF-8 strings, leading
> to the wrong values being passed to wcwidth.
> 
> I fixed this by changing LC_ALL to LC_MESSAGES in gdt, as that was
> the only locale category we needed to change.

Yes, LC_ALL overrides all LC_* values.

Additionally, the values of LC_CTYPE and LC_MESSAGES must be compatible
on glibc systems: They should have the same charset/encoding.
Setting e.g. LC_CTYPE="C" LC_MESSAGES="zh_CN.UTF-8" will not work, because
it will attempt to convert chinese message strings to the encoding of the
"C" locale, which is ASCII.

> However, it had previously been reported that LC_MESSAGES didn't
> work on MS-Windows.

Yes, on native Windows, LC_MESSAGES exists and works only if you are
using either the Gnulib 'setlocale' module or the GNU gettext 
include. Perl doesn't do this; therefore LC_MESSAGES does not exist/work
in Perl on this platform.

Bruno

Re: texinfo-6.8.90 pretest on mingw

[Bruno Haible]

Eli Zaretskii wrote:
> > with a line ending of , which is why
> >   grep 't/infodir/file1.info$'
> > fails.
> 
> I guess Grep that I have (from MSYS) is more tolerant to Windows-style
> CRLF end-of-line format, because it succeeds in that case.

Apparently so, yes. I use the 'grep' from Cygwin, namely GNU grep 3.0,
which is supposed to be POSIX compliant: no special handling of '\r\n'.

Bruno

Re: texinfo-6.8.90 pretest on Solaris 11.4

[Bruno Haible]

Once the compilation error is fixed, "gmake check" fails:

  FAIL: tests/ti-helpversion.sh

Find attached the log.

On this platform, awk is /usr/bin/awk. Not GNU awk. If 'texindex' works only
with GNU awk, it ought to be documented in the manual.



solaris114-failures.tar.gz
Description: application/compressed-tar

Re: texindex awk syntax error

[Bruno Haible]

Gavin Smith wrote:
> It is not supposed to only run on GNU awk.  In fact, it should prefer
> awk to gawk.  I prefer not to run texindex with gawk because mawk is
> much faster.

OK.

> Do you have any idea why awk is saying there is a syntax error?
> 
> awk: syntax error near line 1
> awk: bailing out near line 1

It boils down to this invocation:

$ awk -v Invocation_name=./texindex -f ../../texindex/texindex.awk -- -version
awk: syntax error near line 1
awk: bailing out near line 1

This awk does not support the '-v' option:

$ awk
awk: Usage: awk [-Fc] [-f source | 'cmds'] [files]

$ awk -f ../../texindex/texindex.awk -- -version
awk: syntax error near line 39
awk: bailing out near line 39

Apparently it does not understand the 'function' keyword.

nawk (= /usr/xpg4/bin/awk [2]) and gawk (preinstalled as /usr/bin/gawk [3])
are alternatives which work.

Therefore, on this platform, instead of picking the 'awk' that is found
in $PATH, it is a better strategy to look for 'nawk' or 'gawk' in $PATH.

Bruno

[1] https://docs.oracle.com/cd/E18752_01/html/816-5165/awk-1.html
[2] https://docs.oracle.com/cd/E88353_01/html/E37839/awk-1.html
[3] https://docs.oracle.com/cd/E88353_01/html/E37839/awk-1g.html

Re: mingw-w64 CR handling

[Bruno Haible]

Gavin Smith wrote:
> In info.c the file name is printed with a simple printf:
> 
> printf ("%s\n", ref_list[i]->filename);
> 
> We don't deal with line endings or "text mode" at all here - just
> printing a string to stdout in the most straightforward way.
> 
> It appears that there is some disconnect between the compiler and
> grep on mingw-w64.

Yes. The compiler's runtime prints a newline as  by default,
where the 'grep' program is POSIX-compliant (no special handling of CR/LF).

> hello | grep 'world$'
> 
> would fail?

Yes, it does:

$ ./hello | od -t c
000   H   e   l   l   o   w   o   r   l   d  \r  \n
015

> Yes but I'd rather not complicate the code to deal with s.

OK; that's a different approach to testing than the one I use.

In my packages, I assume a POSIX-compliant environment (grep, awk, etc.)
and filter out CRs *only* from the output of the programs that are part
of my package.

It is also possible to do like Eli does: Use special mingw versions of
the tools (grep, awk, etc.). I believe that in this case you globally
have to handle fewer CRLF problems, but you have them also in other
places than the output of your own programs.

Bruno

Re: texinfo-6.8.90 pretest on OpenSolaris

[Bruno Haible]

On the OpenSolaris derivates
  Solaris 11 OmniOS
  Solaris 11 OpenIndiana
(both in 64-bit mode and in 32-bit mode), 1 test fails:

  FAIL: t/dir-file-sloppily.sh

Find attached the log file.

When I redirect the output of the command
  $ginfo --output - FiLe-M
to a file, I see that is it empty.



solaris11-failures.tar.gz
Description: application/compressed-tar

Re: diff wrapper for install-info tests

[Bruno Haible]

Gavin Smith wrote:
> Could you try a change like the one at the end of this mail?
> 
> If that works, then we can make this change throughout the install-info
> test suite.

With the attached patch, all ii--test tests pass on mingw.

> The test for mingw may need tweaking to include/exclude MinGW, MSYS,
> cygwin...

Yes, it should test the host platform, not the build platform. I used
  echo '@host_os@'
and config.status replaces that with
  echo 'mingw32'

Also I removed the 'v' option from the $EGREP command (since we want the
$EGREP command to succeed, not to fail, in the mingw case), and removed
the 'i' option as well (since all config host values are lowercase ASCII
anyway).

> The --strip-trailing-cr option is specific to GNU diff (not in POSIX) but
> it may be ok for mingw.

Yes, the known environments for compiling mingw binaries (mingw, msys2,
cygwin, debian) all have GNU diff in $PATH.

diff -r -u texinfo-6.8.90.orig/install-info/tests/defs.in texinfo-6.8.90/install-info/tests/defs.in
--- texinfo-6.8.90.orig/install-info/tests/defs.in	2022-04-11 21:34:08.0 +0200
+++ texinfo-6.8.90/install-info/tests/defs.in	2022-10-23 15:52:28.952453136 +0200
@@ -72,6 +72,11 @@
   path_sep=":"
 fi
 
+diff=diff
+if echo '@host_os@' | $EGREP 'mingw' >/dev/null; then
+  diff='diff --strip-trailing-cr'
+fi
+
 # Return true if PROG is somewhere in PATH, else false.
 findprog ()
 {
diff -r -u texinfo-6.8.90.orig/install-info/tests/ii-0001-test texinfo-6.8.90/install-info/tests/ii-0001-test
--- texinfo-6.8.90.orig/install-info/tests/ii-0001-test	2022-02-11 22:56:28.0 +0100
+++ texinfo-6.8.90/install-info/tests/ii-0001-test	2022-10-23 15:52:53.260287035 +0200
@@ -21,7 +21,7 @@
   exit $retval
 fi
 
-diff ${testdir}/ii-0001-expected-dir-file $outputdirfile
+${diff} ${testdir}/ii-0001-expected-dir-file $outputdirfile
 retval=$?
 
 rm -f $outputdirfile
diff -r -u texinfo-6.8.90.orig/install-info/tests/ii-0002-test texinfo-6.8.90/install-info/tests/ii-0002-test
--- texinfo-6.8.90.orig/install-info/tests/ii-0002-test	2022-02-11 22:56:29.0 +0100
+++ texinfo-6.8.90/install-info/tests/ii-0002-test	2022-10-23 15:52:55.996268339 +0200
@@ -21,7 +21,7 @@
   exit $retval
 fi
 
-diff ${testdir}/ii-0002-expected-dir-file $outputdirfile
+${diff} ${testdir}/ii-0002-expected-dir-file $outputdirfile
 retval=$?
 
 rm -f $outputdirfile
diff -r -u texinfo-6.8.90.orig/install-info/tests/ii-0003-test texinfo-6.8.90/install-info/tests/ii-0003-test
--- texinfo-6.8.90.orig/install-info/tests/ii-0003-test	2022-02-11 22:56:27.0 +0100
+++ texinfo-6.8.90/install-info/tests/ii-0003-test	2022-10-23 15:52:58.228253087 +0200
@@ -21,7 +21,7 @@
   exit $retval
 fi
 
-diff ${testdir}/ii-0003-expected-dir-file $outputdirfile
+${diff} ${testdir}/ii-0003-expected-dir-file $outputdirfile
 retval=$?
 
 rm -f $outputdirfile
diff -r -u texinfo-6.8.90.orig/install-info/tests/ii-0004-test texinfo-6.8.90/install-info/tests/ii-0004-test
--- texinfo-6.8.90.orig/install-info/tests/ii-0004-test	2022-02-11 22:56:28.0 +0100
+++ texinfo-6.8.90/install-info/tests/ii-0004-test	2022-10-23 15:53:00.500237561 +0200
@@ -21,7 +21,7 @@
   exit $retval
 fi
 
-diff ${testdir}/ii-0004-expected-dir-file $outputdirfile
+${diff} ${testdir}/ii-0004-expected-dir-file $outputdirfile
 retval=$?
 
 rm -f $outputdirfile
diff -r -u texinfo-6.8.90.orig/install-info/tests/ii-0005-test texinfo-6.8.90/install-info/tests/ii-0005-test
--- texinfo-6.8.90.orig/install-info/tests/ii-0005-test	2022-02-11 22:56:28.0 +0100
+++ texinfo-6.8.90/install-info/tests/ii-0005-test	2022-10-23 15:53:02.828221653 +0200
@@ -21,7 +21,7 @@
   exit $retval
 fi
 
-diff ${testdir}/ii-0005-expected-dir-file $outputdirfile
+${diff} ${testdir}/ii-0005-expected-dir-file $outputdirfile
 retval=$?
 
 rm -f $outputdirfile
diff -r -u texinfo-6.8.90.orig/install-info/tests/ii-0006-test texinfo-6.8.90/install-info/tests/ii-0006-test
--- texinfo-6.8.90.orig/install-info/tests/ii-0006-test	2022-02-11 22:56:27.0 +0100
+++ texinfo-6.8.90/install-info/tests/ii-0006-test	2022-10-23 15:53:05.260205034 +0200
@@ -21,7 +21,7 @@
   exit $retval
 fi
 
-diff ${testdir}/ii-0006-expected-dir-file $outputdirfile
+${diff} ${testdir}/ii-0006-expected-dir-file $outputdirfile
 retval=$?
 
 rm -f $outputdirfile
diff -r -u texinfo-6.8.90.orig/install-info/tests/ii-0007-test texinfo-6.8.90/install-info/tests/ii-0007-test
--- texinfo-6.8.90.orig/install-info/tests/ii-0007-test	2022-02-11 22:56:26.0 +0100
+++ texinfo-6.8.90/install-info/tests/ii-0007-test	2022-10-23 15:53:07.532189508 +0200
@@ -21,7 +21,7 @@
   exit $retval
 fi
 
-diff ${testdir}/ii-0007-expected-dir-file $outputdirfile
+${diff} ${testdir}/ii-0007-expected-dir-file $outputdirfile
 retval=$?
 
 rm -f $outputdirfile
diff -r -u texinfo-6.8.90.orig/install-info/tests/ii-0008-test texinfo-6.8.90/install-info/tests/ii-0008-test
--- texinfo-6.8.90.orig/install-info/tests/ii-0008-test	2022-02-11 22:56:28.0 +0100
+++ 

Re: texinfo-6.8.90 pretest on Solaris 11.4

[Bruno Haible]

On Solaris 11.4, the compilation fails:

gcc -O2 -DHAVE_CONFIG_H -I. -I../../../gnulib/lib -I../..   
-I/export/home/bruno/prefix64/include -Wall -D_REENTRANT  -Wno-cast-qual 
-Wno-conversion -Wno-float-equal -Wno-sign-compare -Wno-undef 
-Wno-unused-function -Wno-unused-parameter -Wno-float-conversion 
-Wimplicit-fallthrough -Wno-pedantic -Wno-sign-conversion -Wno-type-limits 
-Wno-unsuffixed-float-constants -g -O2 -MT libgnu_a-malloca.o -MD -MP -MF 
.deps/libgnu_a-malloca.Tpo -c -o libgnu_a-malloca.o `test -f 'malloca.c' || 
echo '../../../gnulib/lib/'`malloca.c
../../../gnulib/lib/malloca.c:42:56: error: macro "static_assert" requires 2 
arguments, but only 1 given
 static_assert (2 * sa_alignment_max - 1 <= (small_t) -1);
^
../../../gnulib/lib/malloca.c:42:1: warning: data definition has no type or 
storage class
 static_assert (2 * sa_alignment_max - 1 <= (small_t) -1);
 ^
../../../gnulib/lib/malloca.c:42:1: warning: type defaults to ‘int’ in 
declaration of ‘static_assert’ [-Wimplicit-int]
gmake[4]: *** [Makefile:2521: libgnu_a-malloca.o] Error 1

This is the same problem as found in a GNU sed pretest [1]. It needs to be
fixed in Gnulib.

Bruno

[1] https://lists.gnu.org/archive/html/sed-devel/2022-10/msg4.html

Re: texinfo-6.8.90 pretest on mingw

[Bruno Haible]

Eli Zaretskii wrote:
> Which version of Perl did you use in this build?

It's the perl built for and shipped by Cygwin:

$ perl -V
Summary of my perl5 (revision 5 version 26 subversion 1) configuration:
   
  Platform:
osname=cygwin
osvers=2.9.0(0.31853)
archname=x86_64-cygwin-threads-multi
uname='cygwin_nt-6.3 cygwin 2.9.0(0.31853) 2017-09-12 10:18 x86_64 cygwin '
config_args='-des -Dprefix=/usr -Dmksymlinks 
-Darchname=x86_64-cygwin-threads -Dlibperl=cygperl5_26.dll -Dcc=gcc -Dld=g++ 
-Accflags=-ggdb -O2 -pipe -Wimplicit-function-declaration 
-fdebug-prefix-map=/mnt/share/maint/perl.x86_64/build=/usr/src/debug/perl-5.26.1-1
 
-fdebug-prefix-map=/mnt/share/maint/perl.x86_64/src/perl-5.26.1=/usr/src/debug/perl-5.26.1-1
 -fwrapv'
hint=recommended
useposix=true
d_sigaction=define
useithreads=define
usemultiplicity=define
use64bitint=define
use64bitall=define
uselongdouble=undef
usemymalloc=n
default_inc_excludes_dot=define
bincompat5005=undef
  Compiler:
cc='gcc'
ccflags ='-DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__ -D_GNU_SOURCE -ggdb -O2 
-pipe -Wimplicit-function-declaration 
-fdebug-prefix-map=/mnt/share/maint/perl.x86_64/build=/usr/src/debug/perl-5.26.1-1
 
-fdebug-prefix-map=/mnt/share/maint/perl.x86_64/src/perl-5.26.1=/usr/src/debug/perl-5.26.1-1
 -fwrapv -fno-strict-aliasing -fstack-protector-strong -D_FORTIFY_SOURCE=2'
optimize='-O3'
cppflags='-DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__ -D_GNU_SOURCE -ggdb -O2 
-pipe -Wimplicit-function-declaration 
-fdebug-prefix-map=/mnt/share/maint/perl.x86_64/build=/usr/src/debug/perl-5.26.1-1
 
-fdebug-prefix-map=/mnt/share/maint/perl.x86_64/src/perl-5.26.1=/usr/src/debug/perl-5.26.1-1
 -fwrapv -fno-strict-aliasing -fstack-protector-strong'
ccversion=''
gccversion='6.4.0'
gccosandvers=''
intsize=4
longsize=8
ptrsize=8
doublesize=8
byteorder=12345678
doublekind=3
d_longlong=define
longlongsize=8
d_longdbl=define
longdblsize=16
longdblkind=3
ivtype='long'
ivsize=8
nvtype='double'
nvsize=8
Off_t='off_t'
lseeksize=8
alignbytes=8
prototype=define
  Linker and Libraries:
ld='g++'
ldflags =' -Wl,--enable-auto-import -Wl,--export-all-symbols 
-Wl,--enable-auto-image-base -fstack-protector-strong'
libpth=/usr/lib
libs=-lpthread -lgdbm -ldb -ldl -lcrypt -lgdbm_compat
perllibs=-lpthread -ldl -lcrypt
libc=/usr/lib/libcygwin.a
so=dll
useshrplib=true
libperl=cygperl5_26.dll
gnulibc_version=''
  Dynamic Linking:
dlsrc=dl_dlopen.xs
dlext=dll
d_dlsymun=undef
ccdlflags=' '
cccdlflags=' '
lddlflags=' --shared  -Wl,--enable-auto-import -Wl,--export-all-symbols 
-Wl,--enable-auto-image-base -fstack-protector-strong'


Characteristics of this binary (from libperl): 
  Compile-time options:
HAS_TIMES
MULTIPLICITY
PERLIO_LAYERS
PERL_COPY_ON_WRITE
PERL_DONT_CREATE_GVSV
PERL_IMPLICIT_CONTEXT
PERL_OP_PARENT
PERL_PRESERVE_IVUV
PERL_USE_SAFE_PUTENV
USE_64_BIT_ALL
USE_64_BIT_INT
USE_ITHREADS
USE_LARGE_FILES
USE_LOCALE
USE_LOCALE_COLLATE
USE_LOCALE_CTYPE
USE_LOCALE_NUMERIC
USE_LOCALE_TIME
USE_PERLIO
USE_PERL_ATOF
USE_REENTRANT_API
  Locally applied patches:
Cygwin: README
Cygwin: use auto-image-base instead of fixed DLL base address
Cygwin: modify hints
Cygwin: Configure correct libsearch
Cygwin: Configure correct libpth
Cygwin: Win32 correct UTF8 handling
Perl: File-Path-2.14 (fixes CVE2017-6512)
  Built under cygwin
  Compiled at Sep 26 2017 18:57:14
  @INC:
/usr/local/lib/perl5/site_perl/5.26/x86_64-cygwin-threads
/usr/local/share/perl5/site_perl/5.26
/usr/lib/perl5/vendor_perl/5.26/x86_64-cygwin-threads
/usr/share/perl5/vendor_perl/5.26
/usr/lib/perl5/5.26/x86_64-cygwin-threads
/usr/share/perl5/5.26

> What version of Gawk do you have?

GNU awk 4.2.0.

Re: texinfo-6.8.90 pretest on mingw

[Bruno Haible]

Eli Zaretskii wrote:
> > - nearly all of the 'ii--test' tests fail,
> 
> This could be due to Diff.  I have long ago replaced the MSYS Diff
> with the following shell script (and gladly forgot about this issue):
> 
>   #! /bin/sh
>   # diff --- like diff.exe but ignore trailing CR characters
>   /bin/real_diff --strip-trailing-cr $*
> 
> where 'real_diff' is the original Diff program, renamed.

Indeed, the ii-0045-test for example failed because the actual output has
lines ending in  not just .

Re: texinfo-6.8.90 pretest on macOS

[Bruno Haible]

On macOS 10.13, with perl v5.28.3, two tests fail:

FAIL: test_scripts/layout_formatting_info.sh
FAIL: test_scripts/layout_formatting_plaintext.sh

Find attached the logs. It looks like the line breaking is different than
expected.

In case it matters: The Gnulib replacement function 'rpl_wcwidth' is being
compiled:
$ nm gnulib/lib/libgnu_a-wcwidth.o
 U _locale_charset
 T _rpl_wcwidth
 U _uc_width
 U _wcwidth



macOS-failures.tar.gz
Description: application/compressed-tar

Re: texinfo-6.8.90 pretest on mingw

[Bruno Haible]

On mingw (the 'w64' flavour, that can be installed with Cygwin 2.9.0)
- the compilation succeeds,
- there is 1 test failure for 'info',
- nearly all of the 'ii--test' tests fail,
- no test failures in tp/tests/.

The failing 'info' test is:

  FAIL: t/where-dir-file.sh

Find attached the log file.

The output of the command
  $ginfo --where file1
is
  ./../../info/t/infodir/file1.info
with a line ending of , which is why
  grep 't/infodir/file1.info$'
fails.

A possible fix is to replace
  grep 't/infodir/file1.info$'
with
  tr -d '\r' | grep 't/infodir/file1.info$'
Then the test passes.



mingw-failures.tar.gz
Description: application/compressed-tar

Re: conditional "LIBUNISTRING_COMPILE_UNIWIDTH_WIDTH" was never defined.

[Bruno Haible]

Gavin Smith wrote:
> I am trying to update Texinfo to use the latest gnulib code.
> 
> After running gnulib --add-import and running configure,

I could reproduce it like this:
  $ cd texinfo
  $ $GNULIB_SRCDIR/gnulib-tool  --add-import
  $ ./autogen.sh
  $ ./configure

The following patch fixes it. The cause is that texinfo is using the
gnulib-tool option --conditional-dependencies, and a couple of days
ago I made this option more effective.


2022-01-14  Bruno Haible  

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/msg00099.html>.
* m4/libunistring-base.m4 (gl_LIBUNISTRING_MODULE): Use gl_CONDITIONAL
instead of AM_CONDITIONAL.

diff --git a/m4/libunistring-base.m4 b/m4/libunistring-base.m4
index 3815b3e355..a0892da4a6 100644
--- a/m4/libunistring-base.m4
+++ b/m4/libunistring-base.m4
@@ -1,4 +1,4 @@
-# libunistring-base.m4 serial 6
+# libunistring-base.m4 serial 7
 dnl Copyright (C) 2010-2022 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -24,7 +24,7 @@ AC_DEFUN([gl_LIBUNISTRING_MODULE],
   AC_REQUIRE([gl_LIBUNISTRING_LIB_PREPARE])
   dnl Use the variables HAVE_LIBUNISTRING, LIBUNISTRING_VERSION from
   dnl gl_LIBUNISTRING_CORE if that macro has been run.
-  AM_CONDITIONAL(AS_TR_CPP([LIBUNISTRING_COMPILE_$2]),
+  gl_CONDITIONAL(AS_TR_CPP([LIBUNISTRING_COMPILE_$2]),
 [gl_LIBUNISTRING_VERSION_CMP([$1])])
 ])
 

Re: texinfo-6.7.90 tarball contains files that "make distclean" erases

[Bruno Haible]

Hi Gavin, Jacob,

> > > > Also the files MiscXS.c, TestXS.c, XSParagraph.c were included in the
> > > > tarball, although "make clean" or "make distclean" deletes them. There
> > > > are two possible ways to fix this:
> > > 
> > > I think option B below would be the safer one.  We check for xsubpp with
> > > AM_MISSING_PROG so don't currently require it to be available.
> > 
> > I am fairly sure that any system with a perl capable of loading XS modules
> > has a working xsubpp.
> > 
> > As I understand, the .xs file is the proper source file and there are few,
> > if any, guarantees that the generated .c file will work with any perl other
> > than the one used to produce it.  In other words, distributing the .c files
> > xsubpp produces is pointless, as anyone who can use them will also have
> > xsubpp to generate them and weird and bizarre bugs can occur if those files
> > should have been regenerated with the local xsubpp but were taken as
> > distributed for whatever reason.
> 
> That's what you say, but I don't know if it is true.  The fact is we 
> distributed
> the .c file before and nobody reported any problems.  That would be enough on
> its own, but the "perlxs" manual has the following:
> 
>Of course, one could write such glue code directly in C.  However, this
>would be a tedious task, especially if one needs to write glue for
>multiple C functions, and/or one is not familiar enough with the Perl
>stack discipline and other such arcana.  XS comes to the rescue here:
>instead of writing this glue C code in long-hand, one can write a more
>concise short-hand description of what should be done by the glue, and
>let the XS compiler xsubpp handle the rest.
> 
> So I think is better to distribute the .c files unless there's good evidence
> that it causes a problem somewhere.

When you look into the files MiscXS.c, TestXS.c, XSParagraph.c (search for
PERL_VERSION in there) you can see that

  * The generated C code needs to be dependent on the Perl version,
  * xsubpp has produced code that is compatible with older Perl versions.

So, if you produce the tarball with Perl version X and users have a version
compatible to X or smaller than X, everything is fine.

What is not covered is the forward compatibility: If you produce the tarball
with a Perl version that exists today, and in two years the newest Perl
requires different C code and thus the latest xsubpp generates
PERL_VERSION conditionals to cope for this case, you get bug reports
because the files that you have included in the tarball are incompatible.

I would therefore follow Jacob's wisdom.

Bruno

Re: texinfo-6.7.90 pretest on Solaris

[Bruno Haible]

> >> How come that the 'texindex' script is not executable? The Makefile has
> >> built the 'texindex' script like this:
> >>
> >> Making all in texindex
> >> sed -e 's,[@]pkgdatadir[@],/home/haible/prefix-sparc64/share/texinfo,g'  
> >> -e 's,[@]TI_AWK[@],awk,g'  -e 's,[@]PACKAGE[@],texinfo,g'  -e 
> >> 's,[@][@]*VERSION[@][@]*,6.7.90,g' <../../texindex/texindex.in >texindex
> >> chmod +x ../../texindex/texindex
> >> 
> >
> > I don't understand how that is possible as
> > "chmod +x texindex" is hard-coded in the Makefile.
> >   
> 
> VPATH can bring along quite a bit of magic in some makes.  From 
> (make)Missing:
> 
>* In System V and 4.3 BSD `make', files found by `VPATH' search
>  (*note Searching Directories for Prerequisites: Directory Search.)
>  have their names changed inside command strings.  We feel it is
>  much cleaner to always use automatic variables and thus make this
>  feature obsolete.

Jacob is right: it's the quite peculiar VPATH "support" in Solaris 'make'
that does this (changing 'target' to '$(srcdir)/target' in the command).

Solaris 'make' is the only one that this. BSD 'make' either don't support
VPATH or do it reasonably.

Bruno

Re: texinfo-6.7.90 pretest on AIX

[Bruno Haible]

> https://alpha.gnu.org/gnu/texinfo/texinfo-6.7.90.tar.xz

On AIX 7.1, during "make check", one test fails:

Making check in texindex
make  check-TESTS
FAIL: tests/ti-helpversion.sh

Let's look at the log file of this test:

$ cat tests/ti-helpversion.sh.log
+ SHELL=/bin/sh
+ export SHELL
+ CDPATH=
+ unset CDPATH
+ test -z ../../texindex
+ texindex=./texindex
+ TEXINDEX_SCRIPT=../../texindex/texindex.awk
+ export TEXINDEX_SCRIPT
+ + ./texindex --version
 awk: 0602-512 The string Email bug  cannot contain a newline character. The 
source line is 175. The function is usage.
 The error context is
 >>>  <<< general questions and discussion to 
help-texi...@gnu.org.\n\
 Syntax Error The source line is 176. The function is usage.
 awk: 0602-502 The statement cannot be correctly parsed. The source line is 
176. The function is usage.
out=
+ test 2 -ne 0
+ echo ../../texindex/tests/ti-helpversion.sh: ./texindex --version failed.
+ 1>& 2
../../texindex/tests/ti-helpversion.sh: ./texindex --version failed.
+ exit 1
FAIL tests/ti-helpversion.sh (exit status: 1)

So, apparently the chosen awk implementation does not support multi-line
strings.

Which awk implementations are available on this machine?

$ type awk
awk is /usr/bin/awk
$ type mawk
-bash: type: mawk: not found
$ type nawk
nawk is /usr/bin/nawk
$ type gawk
gawk is /usr/bin/gawk
$ gawk --version
GNU Awk 5.0.1, API: 2.0 (GNU MPFR 3.1.2, GNU MP 6.1.2)
Copyright (C) 1989, 1991-2019 Free Software Foundation.
...

So, awk, mawk, and gawk are available. When I change the generated texindex
script to invoke 'gawk' instead of 'awk', "make check" succeeds.

Therefore I think it will be better to prefer 'gawk' to 'awk' in the configure
test. That is, change
  AC_CHECK_PROGS([TI_AWK], [awk mawk gawk], [])
to
  AC_CHECK_PROGS([TI_AWK], [gawk awk mawk], [])

Note: The Autoconf macro AC_PROG_AWK also prefers 'gawk' to all other awk
implementations.

Bruno

texinfo-6.7.90 tarball contains files that "make distclean" erases

[Bruno Haible]

> So, the cause is that an autogenerated and platform-dependent 'texindex'
> script was included in the tarball. Removing it from the tarball will fix
> the issue.

Another way to find this problem is: After unpacking the tarball,
  $ ./configure && make && make distclean
should leave the same tarball contents on disk (with possibly some
empty directories added).

In fact what I see is:
$ LC_ALL=C diff -r -q texinfo-6.7.90.orig texinfo-6.7.90 \
  | sed -e 's|: |/|' \
  | grep -v '/\.deps$'
Only in texinfo-6.7.90/gnulib/lib/sys
Only in texinfo-6.7.90.orig/texindex/texindex
Only in texinfo-6.7.90.orig/tp/Texinfo/XS/MiscXS.c
Only in texinfo-6.7.90.orig/tp/Texinfo/XS/TestXS.c
Only in texinfo-6.7.90.orig/tp/Texinfo/XS/XSParagraph.c
Only in texinfo-6.7.90/tp/Texinfo/XS/gnulib/lib/sys

So, not only the 'texindex' script was included in the tarball.

Also the files MiscXS.c, TestXS.c, XSParagraph.c were included in the
tarball, although "make clean" or "make distclean" deletes them. There
are two possible ways to fix this:

A) Either you consider 'xsubpp' to be a program that can be assumed
   to be present on the target platform. Then there is no need to
   distribute MiscXS.c, TestXS.c, XSParagraph.c in the tarball.
   The Makefile.am should be changed to not distribute these three
   files. Cf.
   
https://www.gnu.org/software/automake/manual/html_node/Fine_002dgrained-Distribution-Control.html

B) Or you consider that 'xsubpp' is not portable enough. Then you
   need to create the three files before doing the tarball, and
   include them in the tarball. Additionally, remove these three
   files from the CLEANFILES variable. And, per GNU Coding Standards
   
   the three files need to be generated in $(srcdir), not in $(builddir).
   So modify the .xs.c rule
 $(XSUBPP) $(XSUBPPARGS) $< > $*.xsc && mv $*.xsc $*.c
   ->
 $(XSUBPP) $(XSUBPPARGS) $< > $*.xsc && mv $*.xsc $(srcdir)/$*.c

Bruno