Thread: MSVC vs Perl
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 0000000012800080, needed
0000000012900080)
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.
That leaves ActiveState Perl as the alternative. The chocolatey package
is no longer maintained, and the last maintained package is no longer
installable. The maintainer says [2]:
To everybody having problems with the ActivePerl installer. I'm
sorry, but I'm not maintaining the package anymore and the reason
for this is as follows. The Chocolatey moderation team requires,
that the download URL and checksum for the actual binary package are
static (for security reasons). However, nowadays ActiveState
provides the community edition download as a weekly build only. This
means that the checksum of the URL changes every week. (The
Chocolatey moderation team proposed that we would setup automation
that would update the version of the Chocolatey package weekly too.
While this would kind-of work, it would still mean that only the
latest version ever would work and every time when the version would
update there would be a short but annoying time window when even the
latest package would be broken. I think this is not the way to go.)
Thus I contacted ActiveState and asked for their support. They were
very friendly and promised to take over the maintenance of the
Chocolatey installer themselves and fix the problem. In my opinion
this is really the best solution and I hope that it will get fixed
soon by the new maintainers. So, for any further questions, it is
probably best to contact the ActiveState support directly.
However, nothing has actually been done along these lines AFAICT.
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.
The upshot of this is that I have disabled building drongo with perl for
now. There will possibly be some fallout with cross version upgrades,
which I will try to prevent.
cheers
andrew
[1]
https://git.postgresql.org/pg/commitdiff/171c7fffaa4a3f2b000f980ecb33c2f7441a9a03
[2] https://community.chocolatey.org/packages/ActivePerl#comment-5484577151
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
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 0000000012800080, needed 0000000012900080) > 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
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
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 0000000012800080, needed
0000000012900080)
>> 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
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
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
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