On Mon, Oct 05, 2026 at 11:31:21PM +0200, Patrice Dumas wrote: > Hello, > > The mingw ucrt clang on MSYS2 platforms in the github CI do not have a > shared libperl, therefore do not have XS nor ctexi2any nor Perl SWIG. > Some C is still compiled, but not used/installed. This still tests > native Perl, and all the tests that are not skipped pass, which is nice > (I would have preferred to skip less tests in tta/perl/t/*.t, see the > other thread).
Is this a regression? In other words, should we expect Texinfo to build on this platform and for the tests to pass? It reminds me of the broken "Cygwin/MinGW" platform which I believe was also on the Github CI. I found some old emails about it. https://lists.gnu.org/archive/html/bug-texinfo/2024-09/msg00014.html https://lists.gnu.org/archive/html/bug-texinfo/2024-10/msg00175.html https://lists.gnu.org/archive/html/bug-texinfo/2024-10/msg00180.html Eli wrote (Sun, 04 Oct 2026 12:42:07 +0300): > Cygwin _is_ different: it emulates a Posix environment, so Texinfo > built with Cygwin tools is supposed to behave like it does on Unix. > That is, any CR characters, if not removed by application code, might > cause trouble if the application is not ready to deal with CRLF EOLs. > > MSYS2 behaves like Cygwin (it's a fork of Cygwin), but that is not > very interesting because MSYS2 programs aren't supposed to be used for > production, only for building Windows programs. So what an MSYS2 > build of texi2any does is IMO not very important because we aren't > supposed to meet such a creature in the wild. So I recommend checking exactly what this platform is before spending any more time on it and whether it is a valid platform to be supporting. Is it a MSYS2 build of texi2any (as Eli describes) or a MinGW build, for example? We used not to depend on libperl - this is one of several issues from the last six months or so which I have planned to revisit. It was only required for embedding a Perl interpreter, which wasn't necessary for texi2any in any of the previously released versions of Texinfo. libperl was not installed on Debian-derived distributions, for example. > The mingw ucrt gcc on MSYS2 platform in the github CI has full XS/C, > that builds fine and the tta/perl/t/*.t tests pass with XS/C too. > > Many tests in tta/tests do not pass, however: > > 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. > It is unexpected since the null device is supposed to be the same > in the main program code and in the conversion to Info code. > Also, strangely, in C, the "NUL" string is used, but "nul" appears in the > error message, although I see nothing in the code that would lowercase > the name. There were also problems with the name of the null device on MinGW/Cygwin. For the second link above: > From: Patrice Dumas > Subject: Re: Texinfo 7.1.90 on mingw > Date: Fri, 25 Oct 2024 23:35:10 +0200 > Those errors are expected. The one about /dev/null happens because the > Perl and executable are native, while the shell is cygwin and not a > "native" shell such as the mingw shell that would map /dev/null to the > native NUL. There are similar errors with path separators that are not > mapped. There is an unknown error that cannot really be understood from > the error log. The other are related to file name encoding. My wild > guess is that the locale of the cygwin shell is not the same as the > locale of the native executables and Perl. Am I wrong in suspecting there may be the same problems with this MSYS2/MinGW setup as there were with the Cygwin/MinGW setup? > 2) the translation of document strings fail both for Perl+XS and > ctexi2any. (They succeed in the tta/perl/t/*.t tests.) > > 3) some tests with ctexi2any crash, but there is no message/dump I can > see/use. > > Unless I have an access to this platform I do not intend to fix those > issues, as they are only possible or much easier to investigate with > direct access. > > -- > Pat >
