> From: Gavin Smith <[email protected]>
> Date: Tue, 13 Jan 2026 18:53:14 +0000
> Cc: [email protected]
>
> On Tue, Jan 13, 2026 at 05:57:44PM +0200, Eli Zaretskii wrote:
> > And does the build really must have ExtUtils::Embed?
>
> No, it shouldn't, as far as I understand. The code that uses an embedded
> perl interpreter is speculative and not used by default. It is only
> used for the alternative ctexi2any implementation of texi2any (not used
> by default), and the SWIG extension interface (not built by default, not
> stable, and not used by any users). (These features may be useful
> in the future, but at the moment do not appear particularly useful.)
> Therefore it seems wrong that we should be tripping over it when trying
> to build the package.
>
> I remember that we discussed ExtUtils::Embed on this list. As I remember,
> this module reports perl configuration values which we could get from
> the output of "perl -V" instead.
>
> https://lists.gnu.org/archive/html/bug-texinfo/2025-11/msg00033.html
>
> Another option is to make the ExtUtils::Embed checks conditional on
> them actually being needed.
I think given the problems it causes it should indeed be conditional.
At least I'd appreciate an option to disable it, because I suspect it
is the single most important problem that stands in my way to build
this pretest.
> > checking ./TestXS.la
> > found ./TestXS.la
> > TestXS: couldn't find name of shared object
> > no fallback module for TestXS
> > checking whether we can build Perl extension (XS) modules... no
> >
> > Any idea why it decides Perl extensions cannot be built? I've built
> > then for Texinfo 7.2, with exactly the same MinGW installation on the
> > same system, with no problems at all. Why does it fail now?
>
> I don't know. That warning message does not make any sense to me (the
> broken English does not help).
>
> Can you check if any shared object is actually built? It would be
> under a directory like 'tta/perl/CheckXS/.libs'.
d:\gnu\texinfo-7.2.90>ls -ltr tta/perl/CheckXS/.libs
total 7
-rw-rw-rw- 1 EliZ None 1717 2026-01-13 16:36 TestXS_la-TestXS.o
-rw-rw-rw- 1 EliZ None 1106 2026-01-13 16:36 TestXS.la
-rw-rw-rw- 1 EliZ None 1968 2026-01-13 16:36 TestXS.a
-rw-rw-rw- 1 EliZ None 1109 2026-01-13 16:36 TestXS.lai
No DLL, as you see.
> tta/perl/CheckXS/TestXS.la
> should contain the location of the file, like:
>
> # Names of this library.
> library_names='TestXS.so TestXS.so TestXS.so'
I have this:
# Names of this library.
library_names=''
# The name of the static archive.
old_library='TestXS.a'
So I think the shared library isn't built, only a static library. And
I think the reason is that libuuid.a is not an import library, so
there's no DLL to which it will link. In such cases libtool builds
only a static library. But the -luuid switch comes from the
requirements of ExtUtils::Embed, so my hope is that if that module is
not required, the linker will not need to look for -luuid, and the
problem will go away.
Is there some easy way for me to try without ExtUtils::Embed, by
setting some variable before running the configure script, or perhaps
by hacking the configure script in some simple way?
> > PERL_EXTUTILS_EMBED_ldopts =
> > It looks like you don't have either nmake.exe or dmake.exe on your PATH,
> > so you will not be able to execute the commands from a Makefile. You can
> > install dmake.exe with the Perl Package Manager by running:
> >
> > ppm install dmake
> >
> > -s -static-libgcc -static-libstdc++ -L"D:\usr\Perl\lib\CORE"
> > -L"C:\MinGW\i686-w64-mingw32\lib" D:\usr\Perl\lib\CORE\libperl520.a
> >
> > which is not in Makefile format. That's the same text I show above
> > emitted by "${PERL} -MExtUtils::Embed -e ldopts". Thus "missing
> > separator".
>
> I see. It's junk from trying to run ExtUtils::Embed that's been put into the
> Makefile.
Yes.
> > So basically all of these problems are caused by ExtUtils::Embed.
>
> The failure to build and load an XS module might not be related, but
> the ExtUtils::Embed problems definitely obscure the issue.
I think the failure to build the XS module is also a consequence of
ExtUtils::Embed, see above.
> > I'm a bit surprised by all these problems, since Texinfo 7.2 built
> > okay for me, and this is supposed to be the next minor release. So I
> > didn't expect a revolution. Could it be that the machinery used here
> > is somehow too fragile (since others reported problems of similar
> > nature on other systems)?
>
> It's actually no surprise to me that we are having all of these problems.
> At the very least, there is a significant increase in the amount of C
> extension code used in texi2any, which has led necessarily to more complexity
> in the build system. There has been a lot of reform to accommodate this
> new code and to try to ensure the program continues to build correctly
> and smoothly, for example using correct compiler flags for different
> parts of the program (compatibility of Perl extension code with gnulib
> code is one possible problem, as far as I understand). On top of that,
> there are the speculative features and alternative non-default implementations
> that are also in the codebase. I expect that more could be done in
> separating the essential and accidental complexity in Texinfo's build
> system.
Maybe the move to C by way of XS modules is not the best idea, given
all the complexities? Maybe it's better to do that in one go, by
rewriting everything in C? That might add bugs, but at least the
build system will be much simpler and will not get in the way. Just a
thought.
