Re: meson/msys2 fails with plperl/Strawberry

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.

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.

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.

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

cheers

andrew

--
Andrew Dunstan
EDB:https://www.enterprisedb.com