public inbox for [email protected]
help / color / mirror / Atom feed[PATCH v18 1/5] introduce routine for checking mutually exclusive string GUCs
7+ messages / 3 participants
[nested] [flat]
* [PATCH v18 1/5] introduce routine for checking mutually exclusive string GUCs
@ 2023-02-15 22:28 Nathan Bossart <[email protected]>
0 siblings, 0 replies; 7+ messages in thread
From: Nathan Bossart @ 2023-02-15 22:28 UTC (permalink / raw)
---
src/backend/postmaster/pgarch.c | 8 +++-----
src/backend/utils/misc/guc.c | 22 ++++++++++++++++++++++
src/include/utils/guc.h | 3 +++
3 files changed, 28 insertions(+), 5 deletions(-)
diff --git a/src/backend/postmaster/pgarch.c b/src/backend/postmaster/pgarch.c
index f97035ca03..dcb5222bbe 100644
--- a/src/backend/postmaster/pgarch.c
+++ b/src/backend/postmaster/pgarch.c
@@ -815,11 +815,9 @@ LoadArchiveLibrary(void)
{
ArchiveModuleInit archive_init;
- if (XLogArchiveLibrary[0] != '\0' && XLogArchiveCommand[0] != '\0')
- ereport(ERROR,
- (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
- errmsg("both archive_command and archive_library set"),
- errdetail("Only one of archive_command, archive_library may be set.")));
+ (void) CheckMutuallyExclusiveStringGUCs(XLogArchiveLibrary, "archive_library",
+ XLogArchiveCommand, "archive_command",
+ ERROR);
/*
* If shell archiving is enabled, use our special initialization function.
diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
index dd5a46469a..b5c8e3702a 100644
--- a/src/backend/utils/misc/guc.c
+++ b/src/backend/utils/misc/guc.c
@@ -2660,6 +2660,28 @@ ReportGUCOption(struct config_generic *record)
pfree(val);
}
+/*
+ * If both parameters are set, emits a log message at 'elevel' and returns
+ * false. Otherwise, returns true.
+ */
+bool
+CheckMutuallyExclusiveStringGUCs(const char *p1val, const char *p1name,
+ const char *p2val, const char *p2name,
+ int elevel)
+{
+ if (p1val[0] != '\0' && p2val[0] != '\0')
+ {
+ ereport(elevel,
+ (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
+ errmsg("cannot set both %s and %s", p1name, p2name),
+ errdetail("Only one of %s or %s may be set.",
+ p1name, p2name)));
+ return false;
+ }
+
+ return true;
+}
+
/*
* Convert a value from one of the human-friendly units ("kB", "min" etc.)
* to the given base unit. 'value' and 'unit' are the input value and unit
diff --git a/src/include/utils/guc.h b/src/include/utils/guc.h
index 3712aba09b..3088ada610 100644
--- a/src/include/utils/guc.h
+++ b/src/include/utils/guc.h
@@ -376,6 +376,9 @@ extern void RestrictSearchPath(void);
extern void AtEOXact_GUC(bool isCommit, int nestLevel);
extern void BeginReportingGUCOptions(void);
extern void ReportChangedGUCOptions(void);
+extern bool CheckMutuallyExclusiveStringGUCs(const char *p1val, const char *p1name,
+ const char *p2val, const char *p2name,
+ int elevel);
extern void ParseLongOption(const char *string, char **name, char **value);
extern const char *get_config_unit_name(int flags);
extern bool parse_int(const char *value, int *result, int flags,
--
2.25.1
--IJpNTDwzlM2Ie8A6
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v18-0002-refactor-code-for-restoring-via-shell.patch"
^ permalink raw reply [nested|flat] 7+ messages in thread
* meson/msys2 fails with plperl/Strawberry
@ 2023-03-25 12:46 Andrew Dunstan <[email protected]>
2023-03-25 16:38 ` Re: meson/msys2 fails with plperl/Strawberry Andres Freund <[email protected]>
0 siblings, 1 reply; 7+ messages in thread
From: Andrew Dunstan @ 2023-03-25 12:46 UTC (permalink / raw)
To: Andres Freund <[email protected]>; PostgreSQL Hackers <[email protected]>
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
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: meson/msys2 fails with plperl/Strawberry
2023-03-25 12:46 meson/msys2 fails with plperl/Strawberry Andrew Dunstan <[email protected]>
@ 2023-03-25 16:38 ` Andres Freund <[email protected]>
2023-03-26 11:57 ` Re: meson/msys2 fails with plperl/Strawberry Andrew Dunstan <[email protected]>
0 siblings, 1 reply; 7+ messages in thread
From: Andres Freund @ 2023-03-25 16:38 UTC (permalink / raw)
To: Andrew Dunstan <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>
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.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?
> (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
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: meson/msys2 fails with plperl/Strawberry
2023-03-25 12:46 meson/msys2 fails with plperl/Strawberry Andrew Dunstan <[email protected]>
2023-03-25 16:38 ` Re: meson/msys2 fails with plperl/Strawberry Andres Freund <[email protected]>
@ 2023-03-26 11:57 ` Andrew Dunstan <[email protected]>
2023-03-26 19:39 ` Re: meson/msys2 fails with plperl/Strawberry Andres Freund <[email protected]>
0 siblings, 1 reply; 7+ messages in thread
From: Andrew Dunstan @ 2023-03-26 11:57 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>
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
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: meson/msys2 fails with plperl/Strawberry
2023-03-25 12:46 meson/msys2 fails with plperl/Strawberry Andrew Dunstan <[email protected]>
2023-03-25 16:38 ` Re: meson/msys2 fails with plperl/Strawberry Andres Freund <[email protected]>
2023-03-26 11:57 ` Re: meson/msys2 fails with plperl/Strawberry Andrew Dunstan <[email protected]>
@ 2023-03-26 19:39 ` Andres Freund <[email protected]>
2023-03-26 21:28 ` Re: meson/msys2 fails with plperl/Strawberry Andres Freund <[email protected]>
0 siblings, 1 reply; 7+ messages in thread
From: Andres Freund @ 2023-03-26 19:39 UTC (permalink / raw)
To: Andrew Dunstan <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>
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
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: meson/msys2 fails with plperl/Strawberry
2023-03-25 12:46 meson/msys2 fails with plperl/Strawberry Andrew Dunstan <[email protected]>
2023-03-25 16:38 ` Re: meson/msys2 fails with plperl/Strawberry Andres Freund <[email protected]>
2023-03-26 11:57 ` Re: meson/msys2 fails with plperl/Strawberry Andrew Dunstan <[email protected]>
2023-03-26 19:39 ` Re: meson/msys2 fails with plperl/Strawberry Andres Freund <[email protected]>
@ 2023-03-26 21:28 ` Andres Freund <[email protected]>
2023-03-27 01:13 ` Re: meson/msys2 fails with plperl/Strawberry Andrew Dunstan <[email protected]>
0 siblings, 1 reply; 7+ messages in thread
From: Andres Freund @ 2023-03-26 21:28 UTC (permalink / raw)
To: Andrew Dunstan <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>
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
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: meson/msys2 fails with plperl/Strawberry
2023-03-25 12:46 meson/msys2 fails with plperl/Strawberry Andrew Dunstan <[email protected]>
2023-03-25 16:38 ` Re: meson/msys2 fails with plperl/Strawberry Andres Freund <[email protected]>
2023-03-26 11:57 ` Re: meson/msys2 fails with plperl/Strawberry Andrew Dunstan <[email protected]>
2023-03-26 19:39 ` Re: meson/msys2 fails with plperl/Strawberry Andres Freund <[email protected]>
2023-03-26 21:28 ` Re: meson/msys2 fails with plperl/Strawberry Andres Freund <[email protected]>
@ 2023-03-27 01:13 ` Andrew Dunstan <[email protected]>
0 siblings, 0 replies; 7+ messages in thread
From: Andrew Dunstan @ 2023-03-27 01:13 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>
> On Mar 26, 2023, at 5:28 PM, Andres Freund <[email protected]> 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
^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2023-03-27 01:13 UTC | newest]
Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2023-02-15 22:28 [PATCH v18 1/5] introduce routine for checking mutually exclusive string GUCs Nathan Bossart <[email protected]>
2023-03-25 12:46 meson/msys2 fails with plperl/Strawberry Andrew Dunstan <[email protected]>
2023-03-25 16:38 ` Re: meson/msys2 fails with plperl/Strawberry Andres Freund <[email protected]>
2023-03-26 11:57 ` Re: meson/msys2 fails with plperl/Strawberry Andrew Dunstan <[email protected]>
2023-03-26 19:39 ` Re: meson/msys2 fails with plperl/Strawberry Andres Freund <[email protected]>
2023-03-26 21:28 ` Re: meson/msys2 fails with plperl/Strawberry Andres Freund <[email protected]>
2023-03-27 01:13 ` Re: meson/msys2 fails with plperl/Strawberry Andrew Dunstan <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox