Re: [HACKERS] pl/perl extension fails on Windows

I wrote: > Short of declaring this version of Perl unsupported, the only answer > I can think of is to put a kluge into the MSVC build scripts along > the lines of "if it's 32-bit Windows, and the Perl version is before X, > assume we need _USE_32BIT_TIME_T even if $Config{ccflags} doesn't > say

Re: [HACKERS] pl/perl extension fails on Windows

I wrote: > Dave Page writes: >> C:\Perl\bin>perl -MConfig -e "print $Config{ccflags}" >> -nologo -GF -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D_CONSOLE -DNO_STRICT >> -DHAVE_DES_FCRYPT -DNO_HASH_SEED -DUSE_SITECUSTOMIZE >> -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO >>

Re: [HACKERS] pl/perl extension fails on Windows

Dave Page writes: > Didn't realise I needed the -MConfig bit (told you my perl-fu was weak :-) > ): > C:\Perl\bin>perl -MConfig -e "print $Config{ccflags}" > -nologo -GF -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D_CONSOLE -DNO_STRICT > -DHAVE_DES_FCRYPT -DNO_HASH_SEED

Re: [HACKERS] pl/perl extension fails on Windows

On Thu, Aug 17, 2017 at 2:58 PM, Tom Lane wrote: > Dave Page writes: > > It's ActiveState Perl 5.8.8. Printing $Config{ccflags} doesn't seem to do > > anything, but perl -V output is below: > > That's weird ... you get nothing from > > perl -MConfig -e

Re: [HACKERS] pl/perl extension fails on Windows

Dave Page writes: > It's ActiveState Perl 5.8.8. Printing $Config{ccflags} doesn't seem to do > anything, but perl -V output is below: That's weird ... you get nothing from perl -MConfig -e 'print $Config{ccflags}' ? regards, tom lane -- Sent

Re: [HACKERS] pl/perl extension fails on Windows

On Mon, Aug 14, 2017 at 9:37 PM, Tom Lane wrote: > I wrote: > > Sandeep Thakkar writes: > >> We built the sources with this patch and were able to create the plperl > >> extension on Windows 32bit and 64bit. > > > Excellent, thanks for

Re: [HACKERS] pl/perl extension fails on Windows

I wrote: > Sandeep Thakkar writes: >> We built the sources with this patch and were able to create the plperl >> extension on Windows 32bit and 64bit. > Excellent, thanks for testing. I'll finish up the configure-script part > and push this shortly. So the

Re: [HACKERS] pl/perl extension fails on Windows

Christoph Berg writes: > HEAD as of 5a5c2feca still has the same problem on kfreebsd. Is there > anything I could dump so we understand the problem better? Yeah, I did not expect that 5a5c2feca would change anything on non-Windows. What we need to do is verify that PL/Perl's

Re: [HACKERS] pl/perl extension fails on Windows

Re: Sandeep Thakkar 2017-08-08 > Hi > > An update from beta3 build: We are no longer seeing this issue (handshake > failure) on Windows 64bit, but on Windows 32bit it still persists. HEAD as of 5a5c2feca still has the same

Re: [HACKERS] pl/perl extension fails on Windows

Sandeep Thakkar writes: > On Thu, Aug 10, 2017 at 9:04 PM, Tom Lane wrote: >> Got it. So in short, it seems like the attached patch ought to fix it >> for MSVC builds. (We'd also need to teach PGAC_CHECK_PERL_EMBED_CCFLAGS >> to let

Re: [HACKERS] pl/perl extension fails on Windows

Hi On Thu, Aug 10, 2017 at 9:04 PM, Tom Lane wrote: > Ashutosh Sharma writes: > > On Thu, Aug 10, 2017 at 8:06 PM, Tom Lane wrote: > >> Yeah ... however, if that's there, then there's something wrong with > >> Ashutosh's

Re: [HACKERS] pl/perl extension fails on Windows

Ashutosh Sharma writes: > On Thu, Aug 10, 2017 at 8:06 PM, Tom Lane wrote: >> Yeah ... however, if that's there, then there's something wrong with >> Ashutosh's explanation, because that means we *are* building with >> _USE_32BIT_TIME_T in 32-bit

Re: [HACKERS] pl/perl extension fails on Windows

On Thu, Aug 10, 2017 at 8:06 PM, Tom Lane wrote: > Robert Haas writes: >> On Thu, Aug 10, 2017 at 8:30 AM, Ashutosh Sharma >> wrote: >>> So, the question is should we allow the preprocessor option >>> '_USE_32BIT_TIME_T' to be

Re: [HACKERS] pl/perl extension fails on Windows

Robert Haas writes: > On Thu, Aug 10, 2017 at 10:36 AM, Tom Lane wrote: >> Yeah ... however, if that's there, then there's something wrong with >> Ashutosh's explanation, because that means we *are* building with >> _USE_32BIT_TIME_T in 32-bit builds.

Re: [HACKERS] pl/perl extension fails on Windows

On Thu, Aug 10, 2017 at 10:36 AM, Tom Lane wrote: > Yeah ... however, if that's there, then there's something wrong with > Ashutosh's explanation, because that means we *are* building with > _USE_32BIT_TIME_T in 32-bit builds. It's just getting there in a > roundabout way.

Re: [HACKERS] pl/perl extension fails on Windows

Robert Haas writes: > On Thu, Aug 10, 2017 at 8:30 AM, Ashutosh Sharma > wrote: >> So, the question is should we allow the preprocessor option >> '_USE_32BIT_TIME_T' to be defined implicitly or not in postgresql >> provided we are using Visual C

Re: [HACKERS] pl/perl extension fails on Windows

On Thu, Aug 10, 2017 at 8:30 AM, Ashutosh Sharma wrote: > So, the question is should we allow the preprocessor option > '_USE_32BIT_TIME_T' to be defined implicitly or not in postgresql > provided we are using Visual C compiler version > 8.0. I think this > should make

Re: [HACKERS] pl/perl extension fails on Windows

On Thu, Aug 10, 2017 at 1:55 AM, Robert Haas wrote: > On Tue, Aug 8, 2017 at 12:15 PM, Sandeep Thakkar > wrote: >> I copied and pasted that portion of the build log into file build.log >> (attached) for Windows 32bit and Windows 64bit. > >

Re: [HACKERS] pl/perl extension fails on Windows

On Tue, Aug 8, 2017 at 12:15 PM, Sandeep Thakkar wrote: > I copied and pasted that portion of the build log into file build.log > (attached) for Windows 32bit and Windows 64bit. Can you also share the output of 'perl -V' on each system? Comparing the 32-bit log

Re: [HACKERS] pl/perl extension fails on Windows

On Tue, Aug 8, 2017 at 8:37 AM, Sandeep Thakkar wrote: > An update from beta3 build: We are no longer seeing this issue (handshake > failure) on Windows 64bit, but on Windows 32bit it still persists. Hmm, maybe you should've reported it sooner, so we could've

Re: [HACKERS] pl/perl extension fails on Windows

Hi An update from beta3 build: We are no longer seeing this issue (handshake failure) on Windows 64bit, but on Windows 32bit it still persists. On Mon, Jul 31, 2017 at 10:15 PM, Christoph Berg wrote: > Re: Tom Lane 2017-07-31 <30582.1501508...@sss.pgh.pa.us> > > Christoph Berg

Re: [HACKERS] pl/perl extension fails on Windows

Re: Tom Lane 2017-07-31 <30582.1501508...@sss.pgh.pa.us> > Christoph Berg writes: > >>> The only interesting line in log/postmaster.log is a log_line_prefix-less > >>> Util.c: loadable library and perl binaries are mismatched (got handshake > >>> key 0xd500080, needed 0xd600080)

Re: [HACKERS] pl/perl extension fails on Windows

Christoph Berg writes: >>> The only interesting line in log/postmaster.log is a log_line_prefix-less >>> Util.c: loadable library and perl binaries are mismatched (got handshake >>> key 0xd500080, needed 0xd600080) Can we see the Perl-related output from configure, particularly

Re: [HACKERS] pl/perl extension fails on Windows

Re: Ashutosh Sharma 2017-07-31 > > The only interesting line in log/postmaster.log is a log_line_prefix-less > > Util.c: loadable library and perl binaries are mismatched (got handshake > > key 0xd500080, needed 0xd600080) > >

Re: [HACKERS] pl/perl extension fails on Windows

Hi Christoph, On Mon, Jul 31, 2017 at 9:18 AM, Ashutosh Sharma wrote: > Hi Christoph, > > On Mon, Jul 31, 2017 at 2:44 AM, Christoph Berg wrote: >> Re: Tom Lane 2017-07-28 <3254.1501276...@sss.pgh.pa.us> >>> Christoph Berg writes: >>> >

Re: [HACKERS] pl/perl extension fails on Windows

Hi Christoph, On Mon, Jul 31, 2017 at 2:44 AM, Christoph Berg wrote: > Re: Tom Lane 2017-07-28 <3254.1501276...@sss.pgh.pa.us> >> Christoph Berg writes: >> > The plperl segfault on Debian's kfreebsd port I reported back in 2013 >> > is also still present: >> >

Re: [HACKERS] pl/perl extension fails on Windows

Christoph Berg writes: > Re: Tom Lane 2017-07-28 <3254.1501276...@sss.pgh.pa.us> >> Christoph Berg writes: >>> The plperl segfault on Debian's kfreebsd port I reported back in 2013 >>> is also still present: >> So it'd be interesting to know if it's any better

Re: [HACKERS] pl/perl extension fails on Windows

Re: Tom Lane 2017-07-28 <3254.1501276...@sss.pgh.pa.us> > Christoph Berg writes: > > The plperl segfault on Debian's kfreebsd port I reported back in 2013 > > is also still present: > > https://www.postgresql.org/message-id/20130515064201.GC704%40msgid.df7cb.de > >

Re: [HACKERS] pl/perl extension fails on Windows

Ashutosh Sharma writes: > I quickly ran the some basic test-cases on my Windows machine (machine > where i have been regenerating the issue) and they are all passing. > Also, all the automated test-cases for contrib module hstore_plperl > are passing. Cool, thanks. I hope

Re: [HACKERS] pl/perl extension fails on Windows

Christoph Berg writes: > The plperl segfault on Debian's kfreebsd port I reported back in 2013 > is also still present: > https://www.postgresql.org/message-id/20130515064201.GC704%40msgid.df7cb.de >

Re: [HACKERS] pl/perl extension fails on Windows

On Sat, Jul 29, 2017 at 12:05 AM, Tom Lane wrote: > Ashutosh Sharma writes: >> On Fri, Jul 28, 2017 at 10:05 PM, Tom Lane wrote: >>> Uh-huh. So the issue is indeed that they're injecting PERL_IMPLICIT_SYS >>> via a command-line

Re: [HACKERS] pl/perl extension fails on Windows

Ashutosh Sharma writes: > On Fri, Jul 28, 2017 at 10:05 PM, Tom Lane 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

Re: [HACKERS] pl/perl extension fails on Windows

On Fri, Jul 28, 2017 at 10:05 PM, Tom Lane wrote: > Ashutosh Sharma writes: >> On Fri, Jul 28, 2017 at 7:22 PM, Tom Lane wrote: >>> Assuming that the Perl crew know what they're doing and this list is >>> complete, I notice that not

Re: [HACKERS] pl/perl extension fails on Windows

Ashutosh Sharma writes: > On Fri, Jul 28, 2017 at 7:22 PM, Tom Lane wrote: >> Assuming that the Perl crew know what they're doing and this list is >> complete, I notice that not one of the symbols they show as relevant >> starts with an underscore. So

Re: [HACKERS] pl/perl extension fails on Windows

On Fri, Jul 28, 2017 at 7:22 PM, Tom Lane wrote: > Ashutosh Sharma writes: >> Thanks for the patch. I am seeing some compilation errors on Windows >> with the patch. Below are the errors observed, >> ... >> I did spent some time to find reason for these

Re: [HACKERS] pl/perl extension fails on Windows

Ashutosh Sharma writes: > Thanks for the patch. I am seeing some compilation errors on Windows > with the patch. Below are the errors observed, > ... > I did spent some time to find reason for these compilation errors and > could eventually find that some of the Windows

Re: [HACKERS] pl/perl extension fails on Windows

Hi, On Fri, Jul 28, 2017 at 4:20 AM, Tom Lane wrote: > > Andrew Dunstan writes: > > On 07/27/2017 04:33 PM, Tom Lane wrote: > >> So I was trying to figure a way to not include XSUB.h except in a very > >> limited part of plperl, like ideally

Re: [HACKERS] pl/perl extension fails on Windows

Andrew Dunstan writes: > On 07/27/2017 04:33 PM, Tom Lane wrote: >> So I was trying to figure a way to not include XSUB.h except in a very >> limited part of plperl, like ideally just the .xs files. It's looking >> like that would take nontrivial refactoring

Re: [HACKERS] pl/perl extension fails on Windows

On 07/27/2017 04:33 PM, Tom Lane wrote: > Robert Haas writes: >> How about we fix it like this? > That seems pretty invasive; I'm not excited about breaking a lot of > unrelated code (particularly third-party extensions) for plperl's benefit. > Even if we wanted to do

Re: [HACKERS] pl/perl extension fails on Windows

Robert Haas writes: > How about we fix it like this? That seems pretty invasive; I'm not excited about breaking a lot of unrelated code (particularly third-party extensions) for plperl's benefit. Even if we wanted to do that in HEAD, it seems like a nonstarter for released

Re: [HACKERS] pl/perl extension fails on Windows

On Thu, Jul 27, 2017 at 10:21 AM, Tom Lane wrote: > Ashutosh Sharma writes: >> Anyways, attached is the patch that corrects this issue. The patch now >> imports all the switches used by perl into plperl module but, after >> doing so, i am seeing some

Re: [HACKERS] pl/perl extension fails on Windows

Andrew Dunstan writes: > What is the minimal set of extra defines required to sort out the > handshake fingerprint issue? Also, exactly what defines do you end up importing in your test build? regards, tom lane -- Sent via pgsql-hackers

Re: [HACKERS] pl/perl extension fails on Windows

On 07/27/2017 12:34 PM, Ashutosh Sharma wrote: > On Thu, Jul 27, 2017 at 7:51 PM, Tom Lane > wrote: > > Ashutosh Sharma > writes: > >> Anyways, attached is the patch that corrects this issue.

Re: [HACKERS] pl/perl extension fails on Windows

On Thu, Jul 27, 2017 at 7:51 PM, Tom Lane wrote: > Ashutosh Sharma writes: >> Anyways, attached is the patch that corrects this issue. The patch now >> imports all the switches used by perl into plperl module but, after >> doing so, i am seeing some

Re: [HACKERS] pl/perl extension fails on Windows

Ashutosh Sharma writes: > Anyways, attached is the patch that corrects this issue. The patch now > imports all the switches used by perl into plperl module but, after > doing so, i am seeing some compilation errors on Windows. Following is > the error observed, > SPI.obj :

Re: [HACKERS] pl/perl extension fails on Windows

Hi All, On Wed, Jul 26, 2017 at 7:56 PM, Ashutosh Sharma wrote: > On Wed, Jul 26, 2017 at 8:51 AM, Tom Lane wrote: >> Robert Haas writes: >>> Based on discussion downthread, it seems like what we actually need to >>> do is

Re: [HACKERS] pl/perl extension fails on Windows

On Wed, Jul 26, 2017 at 8:51 AM, Tom Lane wrote: > Robert Haas writes: >> Based on discussion downthread, it seems like what we actually need to >> do is update perl.m4 to extract CCFLAGS. Turns out somebody proposed >> a patch for that back in 2002:

Re: [HACKERS] pl/perl extension fails on Windows

Robert Haas writes: > Based on discussion downthread, it seems like what we actually need to > do is update perl.m4 to extract CCFLAGS. Turns out somebody proposed > a patch for that back in 2002: >

Re: [HACKERS] pl/perl extension fails on Windows

On Tue, Jul 25, 2017 at 10:23 AM, Robert Haas wrote: > While I'm not sure of the details, I suspect that we need to use one > of those methods to get the CCFLAGS used to build perl, and include > those when SPI.o, Util.o, and plperl.o in src/pl/plperl. Or at least > the -D

Re: [HACKERS] pl/perl extension fails on Windows

On 07/25/2017 11:32 AM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Jul 25, 2017 at 11:00 AM, Tom Lane wrote: >>> Hm, I had the idea that we were already asking ExtUtils::Embed for that, >>> but now I see we only inquire about LDFLAGS not

Re: [HACKERS] pl/perl extension fails on Windows

On Tue, Jul 25, 2017 at 11:32 AM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Jul 25, 2017 at 11:00 AM, Tom Lane wrote: >>> Hm, I had the idea that we were already asking ExtUtils::Embed for that, >>> but now I see we only

Re: [HACKERS] pl/perl extension fails on Windows

Robert Haas writes: > On Tue, Jul 25, 2017 at 11:00 AM, Tom Lane wrote: >> Hm, I had the idea that we were already asking ExtUtils::Embed for that, >> but now I see we only inquire about LDFLAGS not CCFLAGS. Yes, this sounds >> like a promising avenue

Re: [HACKERS] pl/perl extension fails on Windows

On Tue, Jul 25, 2017 at 11:00 AM, Tom Lane wrote: > Hm, I had the idea that we were already asking ExtUtils::Embed for that, > but now I see we only inquire about LDFLAGS not CCFLAGS. Yes, this sounds > like a promising avenue to pursue. > > It would be useful to see the

Re: [HACKERS] pl/perl extension fails on Windows

On 07/25/2017 11:00 AM, Tom Lane wrote: > Robert Haas writes: >> Perl also has a mechanism for flags added to Configure to be passed >> along when building loadable modules; if it didn't, not just plperl >> but every Perl module written in C would have this issue if any

Re: [HACKERS] pl/perl extension fails on Windows

Robert Haas writes: > Perl also has a mechanism for flags added to Configure to be passed > along when building loadable modules; if it didn't, not just plperl > but every Perl module written in C would have this issue if any such > flags where used. > ... > While I'm not

Re: [HACKERS] pl/perl extension fails on Windows

Andrew Dunstan writes: > No amount of checking with the Perl community is likely to resolve this > quickly w.r.t. existing releases of Perl. Yes, but if they are shipping broken perl builds that cannot support building of extension modules, they need to be made

Re: [HACKERS] pl/perl extension fails on Windows

Amit Kapila 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

Re: [HACKERS] pl/perl extension fails on Windows

On 07/25/2017 08:58 AM, Amit Kapila wrote: > > 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. The other tests

Re: [HACKERS] pl/perl extension fails on Windows

On Wed, Jul 19, 2017 at 5:01 PM, Tom Lane wrote: > I am really suspicious that this means your libperl was built in an unsafe > fashion, that is, by injecting configuration choices as random -D switches > in the build process rather than making sure the choices were recorded

Re: [HACKERS] pl/perl extension fails on Windows

On Mon, Jul 24, 2017 at 11:58 AM, Noah Misch wrote: > On Wed, Jul 19, 2017 at 05:01:31PM -0400, Tom Lane wrote: >> Ashutosh Sharma writes: >> > Here are the list of macros and variables from 'intrpvar.h' file that >> > are just defined in perl module but

Re: [HACKERS] pl/perl extension fails on Windows

On Wed, Jul 19, 2017 at 05:01:31PM -0400, Tom Lane wrote: > Ashutosh Sharma writes: > > Here are the list of macros and variables from 'intrpvar.h' file that > > are just defined in perl module but not in plperl on Windows, > > > #ifdef PERL_USES_PL_PIDSTATUS > >

Re: [HACKERS] pl/perl extension fails on Windows

Ashutosh Sharma writes: > Here are the list of macros and variables from 'intrpvar.h' file that > are just defined in perl module but not in plperl on Windows, > #ifdef PERL_USES_PL_PIDSTATUS > PERLVAR(I, pidstatus, HV *) /* pid-to-status mappings for waitpid */ >

Re: [HACKERS] pl/perl extension fails on Windows

Ashutosh Sharma writes: > On Wed, Jul 19, 2017 at 9:42 PM, Tom Lane wrote: >> I imagine the route to a solution is to fix things so that the relevant >> macros are all defined correctly in both cases. But why they aren't >> already is certainly an

Re: [HACKERS] pl/perl extension fails on Windows

On Wed, Jul 19, 2017 at 9:42 PM, Tom Lane wrote: > > Ashutosh Sharma writes: > > Actually the function used for generation of handshake Key i.e HS_KEYp() > > considers 'sizeof(PerlInterpreter)' to generate the key and somehow the > > sizeof

Re: [HACKERS] pl/perl extension fails on Windows

On Wed, Jul 19, 2017 at 12:12 PM, Tom Lane wrote: > Ashutosh Sharma writes: >> Actually the function used for generation of handshake Key i.e HS_KEYp() >> considers 'sizeof(PerlInterpreter)' to generate the key and somehow the >> sizeof PerlInterpreter

Re: [HACKERS] pl/perl extension fails on Windows

Ashutosh Sharma writes: > Actually the function used for generation of handshake Key i.e HS_KEYp() > considers 'sizeof(PerlInterpreter)' to generate the key and somehow the > sizeof PerlInterpreter is not uniform in plperl and perl modules incase of > Windows but on Linux

Re: [HACKERS] pl/perl extension fails on Windows

On Thu, Jul 13, 2017 at 10:30 PM, Tom Lane wrote: > Andrew Dunstan writes: >> It would be nice to get to the bottom of why we're getting a version >> mismatch on Windows, since we're clearly not getting one on Linux. > > Yeah, that's what's

Re: [HACKERS] pl/perl extension fails on Windows

On Thu, Jul 13, 2017 at 6:04 PM, Andrew Dunstan wrote: > > > On 07/13/2017 08:08 AM, Ashutosh Sharma wrote: >> >> After doing some study, I could understand that Util.c is generated >> from Util.xs by xsubpp compiler at build time. This is being done in >>

Re: [HACKERS] pl/perl extension fails on Windows

Re: Dave Page 2017-07-12 > > Well, we have various buildfarm machines running perls newer than that, > > eg, crake, with 5.24.1. So I'd say there is something busted about your > > perl installation. Perhaps leftover bits of

Re: [HACKERS] pl/perl extension fails on Windows

Andrew Dunstan writes: > It would be nice to get to the bottom of why we're getting a version > mismatch on Windows, since we're clearly not getting one on Linux. Yeah, that's what's bothering me: as long as that remains unexplained, I don't have any confidence

Re: [HACKERS] pl/perl extension fails on Windows

On 07/13/2017 10:36 AM, Tom Lane wrote: > Andrew Dunstan writes: >> On 07/13/2017 08:08 AM, Ashutosh Sharma wrote: >>> -dVAR; dXSBOOTARGSAPIVERCHK; >>> +dVAR; dXSBOOTARGSNOVERCHK; >> Good job hunting this down! >> One suggestion I saw in a little googling

Re: [HACKERS] pl/perl extension fails on Windows

Andrew Dunstan writes: > On 07/13/2017 08:08 AM, Ashutosh Sharma wrote: >> -dVAR; dXSBOOTARGSAPIVERCHK; >> +dVAR; dXSBOOTARGSNOVERCHK; > Good job hunting this down! > One suggestion I saw in a little googling was that we add this to the XS > file after the

Re: [HACKERS] pl/perl extension fails on Windows

On 07/13/2017 08:08 AM, Ashutosh Sharma wrote: > > After doing some study, I could understand that Util.c is generated > from Util.xs by xsubpp compiler at build time. This is being done in > Mkvcbuild.pm file in postgres. If I manually replace > 'dXSBOOTARGSAPIVERCHK' macro with

Re: [HACKERS] pl/perl extension fails on Windows

On Thu, Jul 13, 2017 at 12:01 AM, Andrew Dunstan wrote: > On 07/12/2017 11:49 AM, Dave Page wrote: >> >> >> Well crake is a Fedora box - and we have no problems on Linux, only on >> Windows. >> >> > > > Yeah, I have this on one of my Windows boxes, and haven't had

Re: [HACKERS] pl/perl extension fails on Windows

On 07/12/2017 11:49 AM, Dave Page wrote: > > > On Wed, Jul 12, 2017 at 4:35 PM, Tom Lane > wrote: > > Sandeep Thakkar > writes: > > I compiled PG 10

Re: [HACKERS] pl/perl extension fails on Windows

On Wed, Jul 12, 2017 at 4:35 PM, Tom Lane wrote: > Sandeep Thakkar writes: > > I compiled PG 10 beta1/beta2 with "--with-perl" option on Windows and the > > extension crashes the database. > > *src/pl/plperl/Util.c: loadable library and perl

Re: [HACKERS] pl/perl extension fails on Windows

Sandeep Thakkar writes: > I compiled PG 10 beta1/beta2 with "--with-perl" option on Windows and the > extension crashes the database. > *src/pl/plperl/Util.c: loadable library and perl binaries are mismatched > (got handshake key 0A900080, needed 0AC80080)* >