> From: Gavin Smith <[email protected]> > Date: Thu, 8 Oct 2026 23:18:42 +0100 > > 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 depends on whether Clang on Windows can produce XS modules, which in turn depends on whether the native Perl used on the CI platform supports XS modules compiled with Clang. I don't know the answers, as I don't use Clang. > 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 builds of Texinfo have all of the XS and texinfo DLLs dependent on the Perl shared library (in my case, its PERL200.DLL). I don't see how it can be otherwise, since we invoke functions insider libperl. Or what am I missing? > > 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? Yes, because MSYS2 Bash converts /dev/null to NUL when it invokes MinGW programs, whereas the Cygwin Bash does not do this conversion. So problems when using the Cygwin tools are not relevant to what Patrice described.
