Re: MSVC vs Perl - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: MSVC vs Perl
Date
Msg-id e07f13f2-b746-b772-d77c-6a2c8050bda9@dunslane.net
Whole thread Raw
In response to Re: MSVC vs Perl  (Andres Freund <andres@anarazel.de>)
Responses Re: MSVC vs Perl
List pgsql-hackers
On 2022-11-26 Sa 16:05, Andres Freund wrote:
> Hi,
>
> On 2022-11-26 09:43:19 -0500, Andrew Dunstan wrote:
>> OK, so this cures the problem for drongo:
>>
>>
>> diff --git a/src/tools/msvc/Mkvcbuild.pm b/src/tools/msvc/Mkvcbuild.pm
>> index 83a3e40425..dc6b94b74f 100644
>> --- a/src/tools/msvc/Mkvcbuild.pm
>> +++ b/src/tools/msvc/Mkvcbuild.pm
>> @@ -707,6 +707,7 @@ sub mkvcbuild
>>                 print "CFLAGS recommended by Perl: $Config{ccflags}\n";
>>                 print "CFLAGS to compile embedded Perl: ",
>>                   (join ' ', map { "-D$_" } @perl_embed_ccflags), "\n";
>> +               push @perl_embed_ccflags,'NO_THREAD_SAFE_LOCALE';
>>                 foreach my $f (@perl_embed_ccflags)
>>                 {
>>                         $plperl->AddDefine($f);
> This likely is just a test patch, in case it is not, it seems we should add
> NO_THREAD_SAFE_LOCALE to @perl_embed_ccflags before printing it.

Sure

> Do we need a "configure" check for this? I guess it's ok to define this
> whenever building with msvc - I don't currently see a scenario where it could
> hurt. We already define flags unconditionally, c.f. PLPERL_HAVE_UID_GID.
>
> Given how fragile the embedding is (we've had several prior iterations of
> problems around this), I think it'd be good to test that the current flags
> avoid the "got handshake key" at configure time, rather than having to debug
> runtime failures.
>
> As noted by Noah in [1], the Mkvcbuild.pm actually has code to do so - but
> only does for 32bit builds.
>
> I don't think it's worth generalizing this for src/tools/msvc at this point,
> but it might be worth copying the test to meson and running the binary (except
> when cross building, of course).



Yeah, given that we are planning on ditching this build system as soon
as we can I'm not inclined to do anything very heroic.


cheers


andrew

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




pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Allow processes to reset procArrayGroupNext themselves instead of leader resetting for all the followers
Next
From: Daniel Gustafsson
Date:
Subject: Re: pg_regress: Treat child process failure as test failure