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. > Next problem is that configure concludes that XS modules cannot be > built: > > /bin/sh ./libtool --tag=CC --mode=link d:/usr/bin/gcc.exe -s -O2 > -DWIN32 -DPERL_TEXTMODE_SCRIPTS -DUSE_SITECUSTOMIZE -DPERL_IMPLICIT_CONTEXT > -DPERL_IMPLICIT_SYS -DUSE_PERLIO -fwrapv -fno-strict-aliasing -mms-bitfields > -avoid-version -module -s -static-libgcc -static-libstdc++ > -L"D:/usr/Perl/lib/CORE" -L"C:/MinGW/i686-w64-mingw32/lib" -no-undefined -o > TestXS.la -rpath d:/usr/lib/ TestXS_la-TestXS.lo -LD:/usr/Perl/lib/CORE > -lperl520 -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 > -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr > -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32 > libtool: link: ar cr .libs/TestXS.a .libs/TestXS_la-TestXS.o > libtool: link: ranlib .libs/TestXS.a > libtool: link: ( cd ".libs" && rm -f "TestXS.la" && cp -pR "../TestXS.la" > "TestXS.la" ) > libtool: warning: Linker path does not have real file for library -luuid. > libtool: warning: I have the capability to make that library automatically > link in when > libtool: warning: you link to this library. But I can only do this if you > have a > libtool: warning: shared version of the library, which you do not appear to > have > libtool: warning: because I did check the linker path looking for a file > starting > libtool: warning: with libuuid and none of the candidates passed a file > format test > libtool: warning: using a file magic. Last file checked: > d:/usr/lib/libuuid.a > libtool: warning: libtool could not satisfy all declared inter-library > libtool: warning: dependencies of module TestXS. Therefore, libtool will > create > libtool: warning: a static module, that should work as long as the dlopening > libtool: warning: application is linked with the -dlopen flag. > 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'. 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' > And finally, this: > > config.status: creating C/config.h > config.status: executing depfiles commands > config.status: error: in '/d/gnu/texinfo-7.2.90/tta': > config.status: error: Something went wrong bootstrapping makefile fragments > for automatic dependency tracking. If GNU make was not used, consider > re-running the configure script with MAKE="gmake" (or whatever is > necessary). You can also try re-running configure with the > '--disable-dependency-tracking' option to at least be able to build > the package (albeit without support for automatic dependency tracking). > See 'config.log' for more details > configure: error: ./configure failed for tta > > Here's what I see in config.log: > > config.status:3042: executing depfiles commands > config.status:3119: cd C && sed -e '/# am--include-marker/d' Makefile > | make -f - am--depfiles > /d/usr/tmp/Gm195856:1955: *** missing separator. Stop. > > That's because the output of the Sed command includes this around line > 1955: > > 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. > > 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'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. > > Let me know if you need additional information. > > Thanks.
