Re: MSVC vs Perl
On 2022-11-26 Sa 16:25, Andrew Dunstan wrote:
> 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
OK, pushed something like that, after testing that it didn't break my
remaining ActiveState instance.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
Re: MSVC vs Perl
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
Re: MSVC vs Perl
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.
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).
Greetings,
Andres Freund
[1] https://postgr.es/m/20220130231432.GA2658915%40rfd.leadboat.com
Re: MSVC vs Perl
On 2022-11-25 Fr 18:52, Andrew Dunstan wrote:
> On 2022-11-25 Fr 18:48, Andrew Dunstan wrote:
>> For various reasons (see below) it's preferable to build on Windows with
>> Strawberry Perl. This works OK if you're building with Msys2, I upgraded
>> the instance on the machine that runs fairywren and drongo today, and
>> fairywren seems fine. Not so drongo, however. First it encountered a
>> build error, which I attempted to cure using something I found in the
>> vim sources [1]. That worked, but then there's a failure at runtime like
>> this:
>>
>> 2022-11-25 21:33:01.073 UTC [3764:3] pg_regress LOG: statement: CREATE
>> EXTENSION IF NOT EXISTS "plperl"
>> src/pl/plperl/Util.c: loadable library and perl binaries are mismatched (got
>> handshake key 12800080, needed 12900080)
>> 2022-11-25 21:33:01.100 UTC [5048:5] LOG: server process (PID 3764) exited
>> with exit code 1
>>
>> I don't know how to debug this. I'm not sure if there's some flag we
>> could set which would cure it. It looks like a 1 bit difference, but I
>> haven't found what that bit corresponds to.
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);
I'll see if it also works for bowerbird.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
Re: MSVC vs Perl
Hi, On 2022-11-25 18:48:26 -0500, Andrew Dunstan wrote: > I could download the installer from ActiveState, but they want me to > sign up for an account before I do that, which I'm not happy about. And > while I think our use probably comes within their license terms, IANAL > and I'm not dead sure, whereas Strawberry is licensed under the usual > perl license terms. FWIW, my impression is that strawberry perl is of uh, dubious quality. It's definitely rarely updated. I think going with msys' ucrt perl might be the best choice. msys ucrt perl IIRC has the same issues mentioned in [1], but otherwise worked. I wonder if we ought to add a script that installs most of the windows build dependencies from msys. I think there's a few where we can't use msys built versions (due to too much gcc specific stuff ending up in headers), but IIRC most things were usable. It's just too much work to have everyone do this stuff manually. Regards, Andres [1] https://www.postgresql.org/message-id/20220130221659.tlyr2lbw3wk22owg%40alap3.anarazel.de Greetings, Andres Freund
Re: MSVC vs Perl
On 2022-11-25 Fr 18:48, Andrew Dunstan wrote: > For various reasons (see below) it's preferable to build on Windows with > Strawberry Perl. This works OK if you're building with Msys2, I upgraded > the instance on the machine that runs fairywren and drongo today, and > fairywren seems fine. Not so drongo, however. First it encountered a > build error, which I attempted to cure using something I found in the > vim sources [1]. That worked, but then there's a failure at runtime like > this: > > 2022-11-25 21:33:01.073 UTC [3764:3] pg_regress LOG: statement: CREATE > EXTENSION IF NOT EXISTS "plperl" > src/pl/plperl/Util.c: loadable library and perl binaries are mismatched (got > handshake key 12800080, needed 12900080) > 2022-11-25 21:33:01.100 UTC [5048:5] LOG: server process (PID 3764) exited > with exit code 1 > > I don't know how to debug this. I'm not sure if there's some flag we > could set which would cure it. It looks like a 1 bit difference, but I > haven't found what that bit corresponds to. I just saw Andres's post on -committers about this. Will see if that helps me. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
