[I'll divide the issues I found and fixed into several categories, for easier threading of messages.]
> Date: Wed, 14 Jan 2026 00:48:41 +0100 > From: Patrice Dumas <[email protected]> > Cc: Gavin Smith <[email protected]>, [email protected] > > On Tue, Jan 13, 2026 at 05:57:44PM +0200, Eli Zaretskii wrote: > > Tried to build this today. Hit several problems right at the > > beginning, in the configure step. > > > > First, this: > > > > checking ExtUtils::Embed... yes > > Warning (mostly harmless): No library found for -lmoldname > > Warning (mostly harmless): No library found for -lkernel32 > > Warning (mostly harmless): No library found for -luser32 > > Warning (mostly harmless): No library found for -lgdi32 > > Warning (mostly harmless): No library found for -lwinspool > > Warning (mostly harmless): No library found for -lcomdlg32 > > Warning (mostly harmless): No library found for -ladvapi32 > > Warning (mostly harmless): No library found for -lshell32 > > Warning (mostly harmless): No library found for -lole32 > > Warning (mostly harmless): No library found for -loleaut32 > > Warning (mostly harmless): No library found for -lnetapi32 > > Warning (mostly harmless): No library found for -luuid > > Warning (mostly harmless): No library found for -lws2_32 > > Warning (mostly harmless): No library found for -lmpr > > Warning (mostly harmless): No library found for -lwinmm > > Warning (mostly harmless): No library found for -lversion > > Warning (mostly harmless): No library found for -lodbc32 > > Warning (mostly harmless): No library found for -lodbccp32 > > Warning (mostly harmless): No library found for -lcomctl32 > > > > Some (if not all) of these libraries do exist here. And many of them > > don't need to be specified explicitly, since MinGW GCC links against > > them by default. > > > > The message seems to come from this snippet of the configure script: > > > > if test "z$extutils_embed" = 'zyes' ; then > > PERL_EXTUTILS_EMBED_ccopts=`${PERL} -MExtUtils::Embed -e ccopts` > > PERL_EXTUTILS_EMBED_ldopts=`${PERL} -MExtUtils::Embed -e ldopts` > > fi > > My feeling is that this comes ultimately from Perl perllibs. Maybe you > could check the output of > perl -V:perllibs You are right: $ /d/usr/Perl/bin/perl -V:perllibs perllibs='-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32'; All of the libraries it mentions are Windows system libraries. The only exception is -luuid, which is missing. To overcome that problem, I simply built and installed libuuid, which gave me an import library and a DLL. This solved the problem of libtool refusing to build XS as shared libraries. None of the built DLLs actually need libuuid, so its only role here is to pacify the linker, which sees the -luuid switch and therefore must find a corresponding import library in order to be able to produce a DLL. The other problem was to avoid putting junk into tta/C/Makefile because of the error message "perl -MExtUtils::Embed -e ldopts" emits. I suggest to solve this by redirecting its stderr to the null device, like this: PERL_EXTUTILS_EMBED_ccopts= PERL_EXTUTILS_EMBED_ldopts= if test "z$extutils_embed" = 'zyes' ; then PERL_EXTUTILS_EMBED_ccopts=`${PERL} -MExtUtils::Embed -e ccopts 2> /dev/null` PERL_EXTUTILS_EMBED_ldopts=`${PERL} -MExtUtils::Embed -e ldopts 2> /dev/null` fi In addition, I think we should run the output through a Sed script that replaces backslashes with forward slashes. That's because the output is -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 and the backslashes then cause Bash to produce nonsensical file names like D:usrPerllibCORElibperl520.a, which then fails generation of XS shared libraries down the line (libtool doesn't find the file, and assumes it's a static archive, not an import library). Something like this: PERL_EXTUTILS_EMBED_ldopts=`${PERL} -MExtUtils::Embed -e ldopts 2> /dev/null | sed -e 's,\\,/,g'` and similarly with ccopts. I think this can be done on all platforms, since only on Windows Perl might report file names with backslashes. Finally, to avoid the problems with missing dmake (which then causes Perl to include the complaint in the output that is taken as the value of PERL_EXTUTILS_EMBED_ldopts), I simply copied make.exe (which is GNU Make) into dmake.exe, and that was enough to make Perl happy. These measures caused the configure step to succeed and decide correctly that XS modules can be built. Yay!
