Re: meson/msys2 fails with plperl/Strawberry - Mailing list pgsql-hackers

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