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
> And does the build really must have ExtUtils::Embed?
It is the favored way to determine flags for embedding Perl in the
documentation. I just did a commit that removes any use of
ExtUtils::Embed, instead we reconstitute the different parts of
ExtUtils::Embed ccopts and ldopts such that we can be flexible.
> 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 think that it is because I added perllibs flags to the build. The
TestXS link does not use ExtUtils::Embed but use flags that are common
with ExtUtils::Embed ldopts. Indeed, in mingw, be it for Perl embedding
or XS extensions, there is a need to link against libperl, so there
should be consistency in flags used (and same problems).
> 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)?
There are issues with Perl flags being used everywhere, and if these
flags are problematic, as in your case there will be errors.
My feeling, as I said above, is that in the links there are now the
link in the Perl perllibs configuration variable, either from
ExtUtils::Embed or from similar flags we set in m4/txi_perl_conf.m4.
I added those perllibs link flags because it seems the correct thing to
do because it is done that way in ExtUtils::Embed ldopts, and this is
supposed to be the right thing to do, and because it makes sense more
generally (those are supposed to be linking dependencies of libperl).
Now, if the inclusion of perllibs introduces issues instead of being
useful, I will remove it, we could see if it is better without.
--
Pat
