> From: Gavin Smith <[email protected]> > Date: Fri, 9 Oct 2026 17:27:32 +0100 > > > > 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? > > > > On GNU/Linux and Unices, and more generally on platforms where > > -no-undefined is not needed for linking, libperl is not needed when > > linking XS and XS with other C codes at compile/link time, and at > > runtime, the "libperl" that is part of the running interpreter is > > there. Therefore, on these platforms, if texi2any.pl is used, there is > > no need to link against libperl (but it does not hurt either). > > Just to try to explain why invoking "functions inside libperl" does not > mean linking against libperl: these Perl API functions are part of the > Perl interpreter, which is the main program which is running. They don't > become available as a result of loading a dynamic library: they are present > from the start of program execution. > > To be specific, libperl is needed for compiling the XS modules (i.e. the > DLLs) if they call functions that are in the Perl API, because they need > some definition of all symbols used (the same reason why the -no-defined > flag is needed with Libtool). There might be some more to this story (so > as I write this, I wonder whether the libperl for embedding a Perl interpreter > is or needs to be the same libperl used for referencing symbols in the Perl > interpreter), but hopefully the basic idea is clear.
You are describing how things work on Posix systems. They work differently on MS-Windows. On MS-Windows, each XS shared library remembers the Perl DLL against which it was compiled and linked, and will insist on that Perl DLL being loaded when Perl loads the XS. Theoretically, you could be running Perl whose library is a different DLL, and the XS modules will still insist on loading the DLL against which they were linked (which is why it's probably not a good idea to have such a situation, because of possible conflicts between the two Perl DLL versions). IOW, the code in an XS module doesn't call a libperl function that is known to the running Perl, it calls the libperl function in a DLL against which the XS module was linked.
