Re: meson/msys2 fails with plperl/Strawberry

From: Andres Freund <andres(at)anarazel(dot)de>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: meson/msys2 fails with plperl/Strawberry
Date: 2023-03-26 19:39:08
Message-ID: 20230326193908.z3yy2m2647fqyhcs@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2023-03-26 21:14:37 Re: Raising the SCRAM iteration count
Previous Message Andres Freund 2023-03-26 19:26:59 Re: refactoring relation extension and BufferAlloc(), faster COPY