> Date: Sat, 17 Jan 2026 20:33:33 +0100 > From: [email protected] > Cc: Gavin Smith <[email protected]>, [email protected] > > > Since the tests run with Terxinfo uninstalled, I wonder whether the > > test suite harness sets things up so as to find and load the DLLs > > just built. Showing that as part of the test would go a long way > > towards flagging any issues with finding the DLLs, and will also > > indicate which parts of the code were actually tested -- the Perl code > > or the equivalent C code. Right now, I have no idea. And looking in > > config.log and Makefile's doesn't help, because I already know the > > configure script concluded the extensions could be built, and I also > > know that they were in fact built. I just don't know whether they > > were used when running the test suite. > > If you set TEXINFO_XS=debug in the environment, you will see all the > XS modules and XS functions (when the whole module is not overriden, but > some functions are) that are loaded and whether it failed or it was a > success.
OK, I will try using that next time. But won't TEXINFO_XS=debug also show a lot of unrelated stuff, which will flood the terminal with things I'm not interested in? > > Which brings me to the installation. I've just run "make install", > > and I see that various libtexinfo*.dll DLLs are installed in > > $prefix/lib/bin. > > That is somewhat unexpected. In tta/C/Makefile.am, there is > > converterlibdir = $(libdir)/$(CONVERTER) > xsdir = $(converterlibdir) > > and the libraries are in xs_LTLIBRARIES, and therefore should be > installed in $(libdir)/texi2any, since CONVERTER=texi2any. > > xs_LTLIBRARIES += libtexinfo.la I think the reason is libtool. It "knows" that shared libraries on Windows need to be installed in the 'bin' subdirectory, not in the 'lib' subdirectory as on Posix systems. So I guess this calls for some Makefile wizardry, to make sure libtexinfo*.dll libraries end up in lib/texi2any/ instead. > > (Strangely, ctexi2any.exe, > > which I presumed will load them, is not installed.) Are the DLLs > > loaded by explicit dlopen calls, which use their full absolute file > > names? > > Something like that, yes. The libtool .la files are used on some > platforms to find the file names to dlopen. Does Perl code use the *.la files? Because AFAIK libtool is not involved in loading the DLL libraries on Windows at run time. > If the .la files are not > found, the module is dlopened anyway, and it works in platforms that > have rpath or the like, possibly with libtool help and find libraries > without a need to preload through dlopen. Windows doesn't have rpath. > > Another question related to "make install" is why are the *.dll.a > > files installed in lib/texi2any/ ? These are the so-called "import > > libraries", which are needed on Windows to link applications against > > shared libraries. But there's no feature in Texinfo that needs to > > allow other applications to be linked against the DLLs and XS > > extensions produced by the build, is there? > > These are possibly unneeded. But I think that they are installed by > libtool, as we do not install them ourselves. But maybe they are needed > for the C implementation of texi2any? No. The import libraries are only used by the linker at link time. > > The same goes to the *.la > > files -- they are only needed for linking against the libraries (and > > that is not Windows-specific); so why are they installed? > > As I said above, it is probably needed to find the locations of the > libtexinfo* libraries and to load them by Texinfo::XSLoader. So Texinfo::XSLoader accesses the *.la files?
