Re: meson/msys2 fails with plperl/Strawberry

On 2023-03-26 07:57:59 -0400, Andrew Dunstan wrote:
> 
> On 2023-03-25 Sa 12:38, Andres Freund wrote:
> > Hi,
> > 
> > On 2023-03-25 08:46:42 -0400, Andrew Dunstan wrote:
> > > config/perl.m4 contains this:
> > > 
> > > 
> > >     AC_MSG_CHECKING(for flags to link embedded Perl)
> > >     if test "$PORTNAME" = "win32" ; then
> > >          perl_lib=`basename $perl_archlibexp/CORE/perl[[5-9]]*.lib .lib`
> > >          if test -e "$perl_archlibexp/CORE/$perl_lib.lib"; then
> > >              perl_embed_ldflags="-L$perl_archlibexp/CORE -l$perl_lib"
> > >          else
> > >              perl_lib=`basename $perl_archlibexp/CORE/libperl[[5-9]]*.a .a | sed 's/^lib//'`
> > >              if test -e "$perl_archlibexp/CORE/lib$perl_lib.a"; then
> > >                  perl_embed_ldflags="-L$perl_archlibexp/CORE -l$perl_lib"
> > >              fi
> > >          fi
> > >     else
> > >          pgac_tmp1=`$PERL -MExtUtils::Embed -e ldopts`
> > >          pgac_tmp2=`$PERL -MConfig -e 'print "$Config{ccdlflags} $Config{ldflags}"'`
> > >          perl_embed_ldflags=`echo X"$pgac_tmp1" | sed -e "s/^X//" -e "s%$pgac_tmp2%%"`
> > >     fi
> > >     AC_SUBST(perl_embed_ldflags)dnl
> > > 
> > > I don't see any equivalent in meson.build of the win32 logic, and thus I am
> > > getting a setup failure on fairywren when trying to move it to meson, while
> > > it will happily build with autoconf.
> > I did not try to build with strawberry perl using mingw - it doesn't seem like
> > a very interesting thing, given that mingw has a much more reasonable perl
> > than strawberry - but with the mingw perl it works well.
> 
> 
> Strawberry is a recommended perl installation for Windows
> (<https://www.perl.org/get.html>) and is widely used AFAICT.

It also hasn't released anything in years, including security fixes, dumps
broken binaries alongside the directory containing perl.


> In general my approach has been to build as independently as possible from
> msys2 infrastructure, in particular a) not to rely on it at all for MSVC
> builds and b) to use independent third party installations for things like
> openssl and PLs.

Note that the msvc CI build *does* use strawberry perl.

First: I am *not* arguing we shouldn't repair building against strawberry perl
with mingw.

But I fail to see what we gain by using builds of openssl etc from random
places - all that achieves is making it very hard to reproduce problems. Given
how few users mingw built windows has, that's the opposite of what we should
do.


> In any case, I don't think we should be choosing gratuitously to break
> things that hitherto worked, however uninteresting you personally might find
> them.

I didn't gratuitously do so. I didn't even know it was broken - as I said
above, CI tests build with strawberry perl many times a day. I spent plenty
time figuring out why newer perl versions were broken on windows.


> > The above logic actually did *not* work well with mingw for me, because the
> > names are not actually what configure expects, and it seems like a seriously
> > bad idea to encode that much knowledge about library naming and locations.
> 
> 
> Didn't work well how? It just worked perfectly for me with ucrt perl (setup,
> built and tested) using configure:
> 
> $ grep perl532 config.log
> configure:10482: result: -LC:/tools/nmsys64/ucrt64/lib/perl5/core_perl/CORE
> -lperl532
> configure:18820: gcc -o conftest.exe -Wall -Wmissing-prototypes
> -Wpointer-arith -Wdeclaration-after-statement -Werror=vla -Wendif-labels
> -Wmissing-format-attribute -Wimplicit-fallthrough=3 -Wcast-function-type
> -Wshadow=compatible-local -Wformat-security -fno-strict-aliasing -fwrapv
> -fexcess-precision=standard -Wno-format-truncation -Wno-stringop-truncation
> -O2 -I./src/include/port/win32
> -IC:/tools/nmsys64/ucrt64/lib/perl5/core_perl/CORE
> -Wl,--allow-multiple-definition -Wl,--disable-auto-import conftest.c
> -LC:/tools/nmsys64/ucrt64/lib/perl5/core_perl/CORE -lperl532 >&5
> perl_embed_ldflags='-LC:/tools/nmsys64/ucrt64/lib/perl5/core_perl/CORE
> -lperl532'

I got mismatches around library names, because some of the win32 specific
pattern matches didn't apply or applied over broadly. I don't have a windows
system running right now, I'll try to reproduce in the next few days.


> > > I would expect the ld flags to be "-LC:/STRAWB~1/perl/lib/CORE -lperl532"
> > You didn't say what they ended up as?
> 
> 
> I think you misunderstand me. This is what they should end up as.

I know. Without knowing what they *did* end up as, it's hard to compare, no?

Greetings,

Andres Freund