Subject: meson/msys2 fails with plperl/Strawberry

From: Andrew Dunstan <[email-masked]>
Date: Sat, 25 Mar 2023 08:46:42 -0400

Hi,

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 would expect the ld flags to be "-LC:/STRAWB~1/perl/lib/CORE -lperl532"

(Off topic peeve - one of the things I dislike about meson is that the 
meson.build files are written in YA bespoke language).

cheers

andrew

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

---

From: Andres Freund <[email-masked]>
Date: Sat, 25 Mar 2023 09:38:18 -0700

Hi,

On 2023-03-25 08:46:42 -0400, Andrew Dunstan wrote:
> 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.

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.

https://cirrus-ci.com/task/6421536551206912

[16:32:28.997] Has header "perl.h" : YES
[16:32:28.997] Message: CCFLAGS recommended by perl:  -DWIN32 -DWIN64 -DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -D__USE_MINGW_ANSI_STDIO -fno-strict-aliasing -mms-bitfields
[16:32:28.997] Message: CCFLAGS for embedding perl: -IC:\msys64\ucrt64\lib\perl5\core_perl/CORE -DWIN32 -DWIN64 -DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPLPERL_HAVE_UID_GID
[16:32:28.997] Message: LDFLAGS recommended by perl: "-s -L"C:\msys64\ucrt64\lib\perl5\core_perl\CORE" -L"C:\msys64\ucrt64\lib"  "C:\msys64\ucrt64\lib\perl5\core_perl\CORE\libperl532.a" "C:\msys64\ucrt64\lib\libmoldname.a" "C:\msys64\ucrt64\lib\libkernel32.a" "C:\msys64\ucrt64\lib\libuser32.a" "C:\msys64\ucrt64\lib\libgdi32.a" "C:\msys64\ucrt64\lib\libwinspool.a" "C:\msys64\ucrt64\lib\libcomdlg32.a" "C:\msys64\ucrt64\lib\libadvapi32.a" "C:\msys64\ucrt64\lib\libshell32.a" "C:\msys64\ucrt64\lib\libole32.a" "C:\msys64\ucrt64\lib\liboleaut32.a" "C:\msys64\ucrt64\lib\libnetapi32.a" "C:\msys64\ucrt64\lib\libuuid.a" "C:\msys64\ucrt64\lib\libws2_32.a" "C:\msys64\ucrt64\lib\libmpr.a" "C:\msys64\ucrt64\lib\libwinmm.a" "C:\msys64\ucrt64\lib\libversion.a" "C:\msys64\ucrt64\lib\libodbc32.a" "C:\msys64\ucrt64\lib\libodbccp32.a" "C:\msys64\ucrt64\lib\libcomctl32.a""
[16:32:28.997] Message: LDFLAGS for embedding perl: "C:\msys64\ucrt64\lib\perl5\core_perl\CORE\libperl532.a C:\msys64\ucrt64\lib\libmoldname.a C:\msys64\ucrt64\lib\libkernel32.a C:\msys64\ucrt64\lib\libuser32.a C:\msys64\ucrt64\lib\libgdi32.a C:\msys64\ucrt64\lib\libwinspool.a C:\msys64\ucrt64\lib\libcomdlg32.a C:\msys64\ucrt64\lib\libadvapi32.a C:\msys64\ucrt64\lib\libshell32.a C:\msys64\ucrt64\lib\libole32.a C:\msys64\ucrt64\lib\liboleaut32.a C:\msys64\ucrt64\lib\libnetapi32.a C:\msys64\ucrt64\lib\libuuid.a C:\msys64\ucrt64\lib\libws2_32.a C:\msys64\ucrt64\lib\libmpr.a C:\msys64\ucrt64\lib\libwinmm.a C:\msys64\ucrt64\lib\libversion.a C:\msys64\ucrt64\lib\libodbc32.a C:\msys64\ucrt64\lib\libodbccp32.a C:\msys64\ucrt64\lib\libcomctl32.a"
[16:32:28.997] Checking if "libperl" : links: YES

> I would expect the ld flags to be "-LC:/STRAWB~1/perl/lib/CORE -lperl532"

You didn't say what they ended up as?

> meson.build files are written in YA bespoke language).

I don't really disagree. However, all the general purpose language using build
etools I found were awful. And meson's language is a heck of a lot nicer than
e.g. cmake's...

Greetings,

Andres Freund

---

From: Andrew Dunstan <[email-masked]>
Date: Sun, 26 Mar 2023 07:57:59 -0400

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

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

> You didn't say what they ended up as?

I think you misunderstand me. This is what they should end up as.

cheers

andrew

---

From: Andres Freund <[email-masked]>
Date: Sun, 26 Mar 2023 12:39:08 -0700

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

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

> Didn't work well how? It just worked perfectly for me with ucrt perl (setup,
> built and tested) using configure:
> 
> configure:10482: result: -LC:/tools/nmsys64/ucrt64/lib/perl5/core_perl/CORE
> -lperl532
> -fexcess-precision=standard -Wno-format-truncation -Wno-stringop-truncation
> -O2 -I./src/include/port/win32

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 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: Andres Freund <[email-masked]>
Date: Sun, 26 Mar 2023 14:28:30 -0700

Hi,

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

Hm - can you describe the failure more - I just tried, and it worked to build
against strawberry perl on mingw, without any issues. All I did was set
-DPERL="c:/strawberrly/perl/bin/perl.exe".

Greetings,

Andres Freund

---

From: Andrew Dunstan <[email-masked]>
Date: Sun, 26 Mar 2023 21:13:41 -0400

> On Mar 26, 2023, at 5:28 PM, Andres Freund <[email-masked]> wrote:
> 
> Hi,
> 

That might be the secret sauce I’m missing. I will be offline for a day or three, will test when I’m back.

Cheers 

Andrew