Horton

Re: pl/perl extension fails on Windows

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Ashutosh Sharma <ashu.coek88@gmail.com>
Cc: Magnus Hagander <magnus@hagander.net>, Andrew Dunstan <andrew.dunstan@2ndquadrant.com>, Robert Haas <robertmhaas@gmail.com>, Dave Page <dpage@pgadmin.org>, Sandeep Thakkar <sandeep.thakkar@enterprisedb.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2017-07-28T18:35:21Z
Lists: 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

Commits

  1. MSVC: Test whether 32-bit Perl needs -D_USE_32BIT_TIME_T.

  2. Further tweaks to compiler flags for PL/Perl on Windows.

  3. Absorb -D_USE_32BIT_TIME_T switch from Perl, if relevant.

  4. PL/Perl portability fix: absorb relevant -D switches from Perl.

  5. PL/Perl portability fix: avoid including XSUB.h in plperl.c.