> Date: Wed, 7 Oct 2026 21:51:05 +0200 > From: Patrice Dumas <[email protected]> > Cc: [email protected] > > On Wed, Oct 07, 2026 at 04:43:13PM +0300, Eli Zaretskii wrote: > > > Date: Mon, 5 Oct 2026 23:31:21 +0200 > > > From: Patrice Dumas <[email protected]> > > > > > > 1) there is a test with -o /dev/null and --split-size 1, to make sure that > > > the resuting Info file is non-split. /dev/null is substituted by the > > > platform null device in the main program (in tests), and if the output > > > file name is the platform null device non-split is supposed to be > > > chosen in conversion to Info. The test fails both for Perl with XS > > > and ctexi2any, the Info file remains split. > > > > I the "-o /dev/null" is in a shell scvript, then the MSYS2 Bash will > > convert that to the native Windows null device when invoking MinGW > > texi2any. So in that case there's no reason to replace /dev/null, and > > maybe the fact that you do causes the problem (but I didn't look at > > the code or the failures, so apologies if what I say makes no sense). > > > > See above: maybe MSYS2 did the job for you? > > This seems like a good hypothesis, probably MSYS2 uses nul and not NUL, > so it does not match. I can fix that by making the comparison > independent of the string case for nul.
File-name comparison for the MinGW build of Texinfo should be case-insensitive anyway, because the OS filesystem is. > > > 2) the translation of document strings fail both for Perl+XS and > > > ctexi2any. (They succeed in the tta/perl/t/*.t tests.) > > > > What do you mean by "translation of document strings" and what are > > the details of the failures? > > The strings in the output document are not translated. For example, the > french language "Section suivante dans l’ordre de lecture" is not > used: > > -<td class="nav-button">[<a href="#chapter" title="Section suivante dans > l’ordre de lecture" rel="next"> > </a>]</td> > +<td class="nav-button">[<a href="#chapter" title="Next section in reading > order" rel="next"> > </a>]</td> > > It is not so easy to debug that kind of error without access to the > platform because gettext does not say why the string is not found, one > has to use prints and strace or similar to get an idea what is going wrong. If the translation comes from gettext, perhaps Bruno (CC'ed) could suggest what could be the reasons for this? One possible cause could be that the Windows setlocale doesn't look at the LC_* environment variables (unless you are using Gnulib replacements). Another possibility is if you rely on the LC_MESSAGES category, which Windows doesn't support. Regarding your previous report of crashes in the test suite: historically, most if not all such crashes I encountered were because of mismatch between allocation of memory and freeing it: either allocation via Perl and freeing via a direct call to 'free', or the other way around, allocation via 'malloc' with subsequent freeing via Perl. They use different 'malloc'/'free' implementations that use different memory pools, so this usually causes aborts and crashes. So maybe look into such possibilities in the code involved in crashing. HTH
