Thread: meson/msys2 fails with plperl/Strawberry
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
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.
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.aC:\msys64\ucrt64\lib\libkernel32.a C:\msys64\ucrt64\lib\libuser32.a
C:\msys64\ucrt64\lib\libgdi32.aC:\msys64\ucrt64\lib\libwinspool.a C:\msys64\ucrt64\lib\libcomdlg32.a
C:\msys64\ucrt64\lib\libadvapi32.aC:\msys64\ucrt64\lib\libshell32.a C:\msys64\ucrt64\lib\libole32.a
C:\msys64\ucrt64\lib\liboleaut32.aC:\msys64\ucrt64\lib\libnetapi32.a C:\msys64\ucrt64\lib\libuuid.a
C:\msys64\ucrt64\lib\libws2_32.aC:\msys64\ucrt64\lib\libmpr.a C:\msys64\ucrt64\lib\libwinmm.a
C:\msys64\ucrt64\lib\libversion.aC:\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?
> (Off topic peeve - one of the things I dislike about meson is that the
> 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
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
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
Hi, On 2023-03-26 12:39:08 -0700, Andres Freund wrote: > First: I am *not* arguing we shouldn't repair building against strawberry perl > with mingw. 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
> On Mar 26, 2023, at 5:28 PM, Andres Freund <andres@anarazel.de> wrote: > > Hi, > >> On 2023-03-26 12:39:08 -0700, Andres Freund wrote: >> First: I am *not* arguing we shouldn't repair building against strawberry perl >> with mingw. > > 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". > > 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
Hi, On 2023-03-26 21:13:41 -0400, Andrew Dunstan wrote: > > On Mar 26, 2023, at 5:28 PM, Andres Freund <andres@anarazel.de> wrote: > >> On 2023-03-26 12:39:08 -0700, Andres Freund wrote: > >> First: I am *not* arguing we shouldn't repair building against strawberry perl > >> with mingw. > > > > 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". > That might be the secret sauce I’m missing. I will be offline for a day or three, will test when I’m back. It should suffice to put strawberry perl first in PATH. All that the -DPERL does is to use that, instead of 'perl' from PATH. If putting strawberry perl ahead in PATH failed, something else must have been going on... Greetings, Andres Freund
On 2023-03-27 Mo 13:18, Andres Freund wrote:
Hi, On 2023-03-26 21:13:41 -0400, Andrew Dunstan wrote:On Mar 26, 2023, at 5:28 PM, Andres Freund <andres@anarazel.de> wrote:On 2023-03-26 12:39:08 -0700, Andres Freund wrote: First: I am *not* arguing we shouldn't repair building against strawberry perl with mingw.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".That might be the secret sauce I’m missing. I will be offline for a day or three, will test when I’m back.It should suffice to put strawberry perl first in PATH. All that the -DPERL does is to use that, instead of 'perl' from PATH. If putting strawberry perl ahead in PATH failed, something else must have been going on...
Yeah, What it actually needed was a system upgrade. Sorry for the noise.
cheers
andrew
-- Andrew Dunstan EDB: https://www.enterprisedb.com