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 so

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 >> -DPERL_MSVCRT_READFIX

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 -DUSE_SITECUSTOMIZE > -DPERL_IMPLICI

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 'print $Config{ccflags}' > Didn't realise

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 via pgsql-hackers mailin

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 testing. I'll finish up the configure-script part > > and p

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 early returns from the buildfarm are t

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 idea of sizeof(PerlI

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 problem on kfreebsd. Is there anything I could dump so we understand the

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 _USE_32BIT_TIME_T through on Windows, but let's confirm the th

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 explanation, because that means we *are* building with > >> _USE_32BIT_TI

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 builds. It's just getting there in a >> roundabou

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 defined implicitly or not in postgresql >>> provided we are using Vi

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. It's just getting there in a >> roundabout w

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. (Or, alternatively, th

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 compiler version > 8.0. I think this >> should mak

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 plperl compatible with perl

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. > > Can you also share the output of 'perl -V' on each system

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 and the 64-bit log, I see the foll

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 tried to fix this before beta3 went o

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 writes: > > >>>

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) > > Can we see t

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 the new lines abo

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) > > ... which is unchanged from the beta2 output. > > > I am not able t

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: >>> > The plperl segfault on Debian's kfreebsd port I reported b

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: >> > https://www.postgresql.org/message-

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 with HEAD ... > Unfortunately not:

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 > > https://buildd.debian.org/status

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 people will set up some

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 > https://buildd.debian.org/status/fetch.php?pkg=postgresql-10&arch=kfreebsd-amd64&ver=10~beta2-1&st

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 #define rather than putting it into perl's config.h, >>> and that r

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 change in the apparent size of the PerlInterp

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 one of the symbols they show as relevant >>> starts with an und

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 I'm thinking that my previous semi- >> jokin

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 compilation errors and >> could eventually

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 specific functions > inside

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 just the .xs files. It's looking > >> like that would

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 though :-(. Another problem >> is tha

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 that in HEAD, it seems like

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 branches. An even bigg

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 compilation errors on Windows. Following is >>

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 mailing list (pgsql-hackers@post

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. The patch now > >> imports all the switches us

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 compilation errors on Windows. Following is >>

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 : error LNK2019: unresolv

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 update perl.m4 to extract CCFLAGS. Turns out somebody proposed >>> a pa

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: >> https://www.postgresql.org/message-id/Pine

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: > https://www.postgresql.org/message-id/Pine.LNX.4.44.0211051045070.16317-20%40wotan.suse.de > I

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 switches from those CCF

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 CCFLAGS. Yes, this sounds >>> like a promising ave

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 inquire about LDFLAGS not CCFLAGS. Yes, this sounds >>> like a prom

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 to pursue. >> >> It would be useful to see

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 results of > > perl -MExt

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 such >> flags where used.

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 sure of the details, I su

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 aware of that. If that *isn't* the

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 seems like the wrong route t

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 an

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 in > perl's config.h.

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 not in plperl on Windows, >> >> > #ifdef P

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 > > PERLVAR(I, pidstatus, HV *)

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 */ > #endif > #ifdef PERL_SA

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 interesting question. Have you identified just

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 PerlInterpreter is not uniform in plperl and perl module

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 is not uniform in plperl and perl modules in

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 it remains same in both t

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 bothering me: as long as that remains unexplained, > I d

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 >> Mkvcbuild.pm file in postgres. If I manua

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 an older version somewhere? > > > > Well crake is a Fedora box - and

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 that we're fixing the right thing.

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 was that we add this to the XS >

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 inclusion of XSUB.h: > #unde

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 'dXSBOOTARGSNOVE

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 time to > get to the bottom of it

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 beta1/beta2 with "--with-perl" option on > Windows and the >

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 binaries are mismatched > > (got handshake key 0A90008

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)* > This is seen with Perl 5.24 but not w