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
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 |