> Date: Sat, 17 Jan 2026 21:43:44 +0100 > From: [email protected] > Cc: [email protected], [email protected] > > > > 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? > > No, it will mainly show that, but there are lots of functions and > modules, so it will flood the terminal nonetheless. Also it shows every > function when you are probably only interested in one from that file.
Thanks for the heads-up. Maybe I will then do this only when running a single test, since the arrangement of loading extensions is the same for all of the test. > > > > 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. > > Ok. I guess we have to bypass libtool on that. Probably. How do you arrange for the XS DLLs to be installed in lib/texi2any? You should probably do the same with the libtexinfo*.dll. In fact, I now see that in Texinfo 7.2 the libtexinfo*.dll files were installed together with the XS DLL files. Was that because you didn't use libtool back then? > That being said, this could come handy for the SWIG interface as for the > SWIG interface, we do not have the custom XSLoader and we need to load > the libraries. So, maybe we should install in both locations or > something like that. Which program or DLL will load the SWIG libraries? Anyway, it's okay to install in two locations, but the other location should be $prefix/bin, not $prefix/lib/bin, because the latter is unlikely to be on PATH. > > > > (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. > > Yes, it is Texinfo::XSLoader code that does that. Oh. Then it means the installation is not "relocatable", i.e. the absolute file names written in the *.la files must be the places where the libraries are installed. Or is there some environment variable that can be set to override that? To be "relocatable", file names should be relative to some common root, so that the entire installation tree could be moved to a different location, and the programs will still work. This is especially important on Windows, where many people don't build packages for their systems, but instead download prebuilt binaries and install them according to their local arrangements of the directory tree. Previous Texinfo releases didn't impose such restrictions, AFAIR. Of course, in practice this didn't really matter, because the binary distributions of Texinfo I upload to my ezwinports site don't include the DLL files, since those are specific to my version of Perl. And the Perl files in $prefix/lib and in $prefix/share/texinfo are not loaded using absolute file names, are they? > > > > 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. > > Ok, then they are not needed. I do not think that it is problematic to > leave them there, though. Similar .so that are only used to link are > also present in GNU/Linux. Right, you can leave them there, and if someone is worried about that, they can delete them after installation. > > > > 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? > > Yes. Maybe this should be documented on some README or in the Texinfo/texi2any manual, including the logic used by Texinfo::XSLoader to find the libraries? I couldn't find it in the manuals, maybe I missed something. This information might be valuable for people who distribute the binaries and for people who install them.
