Re: [HACKERS] pl/perl extension fails on Windows - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] pl/perl extension fails on Windows
Date
Msg-id 25248.1501266921@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] pl/perl extension fails on Windows  (Ashutosh Sharma <ashu.coek88@gmail.com>)
Responses Re: [HACKERS] pl/perl extension fails on Windows
List pgsql-hackers
Ashutosh Sharma <ashu.coek88@gmail.com> writes:
> On Fri, Jul 28, 2017 at 10:05 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Uh-huh.  So the issue is indeed that they're injecting PERL_IMPLICIT_SYS
>> via a command-line #define rather than putting it into perl's config.h,
>> and that results in a change in the apparent size of the PerlInterp
>> struct (because of IMem and friends).

> Yes, That's right. We would have seen different result if the
> PERL_IMPLICIT_SYS would not have been defined globally.

I've pushed the changes to the build scripts now.  I had to revise the
Mkvcbuild.pm part a bit, because you'd forgotten to propagate the extra
defines into hstore_plperl.  So that code is untested; please confirm
that HEAD works in your problem environment now.

I notice that Mkvcbuild.pm is artificially injecting a define for
PLPERL_HAVE_UID_GID.  I strongly suspect that that was a hack meant
to work around the lack of this mechanism, and that we could now
get rid of it or clean it up.  But there's no evidence in the commit
log about the reason for it --- it seems to go back to the original
addition of MSVC support.  Anybody remember?
        regards, tom lane



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] [patch] pg_dump/pg_restore zerror() and strerror()mishap
Next
From: Vladimir Kunschikov
Date:
Subject: Re: [HACKERS] [patch] pg_dump/pg_restore zerror() and strerror() mishap