Re: pl/perl extension fails on Windows

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

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Noah Misch <noah@leadboat.com>, Ashutosh Sharma <ashu.coek88@gmail.com>, Andrew Dunstan <andrew.dunstan@2ndquadrant.com>, Dave Page <dpage@pgadmin.org>, Sandeep Thakkar <sandeep.thakkar@enterprisedb.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2017-07-25T14:38:02Z
Lists: pgsql-hackers
Amit Kapila <amit.kapila16@gmail.com> writes:
> I think the real question is where do we go from here.  Ashutosh has
> proposed a patch up-thread based on a suggestion from Andrew, but it
> is not clear if we want to go there as that seems to be bypassing
> handshake mechanism.

That definitely seems like the wrong route to me.  If the resulting
code works, it would at best be accidental.

> The other tests and analysis seem to indicate
> that the new version Perl binaries on Windows are getting built with
> flags that are incompatible with what we use for plperl and it is not
> clear why perl is using those flags.  Do you think we can do something
> at our end to make it work or someone should check with Perl community
> about it?

It would be a good idea to find somebody who knows more about how these
Perl distros are built.

			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.