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 17646.1502983856@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] pl/perl extension fails on Windows  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] pl/perl extension fails on Windows  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
I wrote:
> Dave Page <dpage@postgresql.org> 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

> So it is indeed not advertising anything about _USE_32BIT_TIME_T ...
> but then how do other Perl extensions work?  Strange.

So we're between a rock and a hard place here.  ActiveState Perl 5.8.8
requires us to use _USE_32BIT_TIME_T, and doesn't appear to display that
requirement in any standard way.  Newer versions of Perl require us not
to use that symbol unless they say so.

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".  It would be nice to have some hard evidence about what X
should be, but we don't know when ActiveState fixed this.  (I poked
around in their bugzilla, without success.)

In the interests of getting the buildfarm green again before I disappear
on vacation, I propose to do the above with X = 5.10.0.  Anybody
have a better idea?
        regards, tom lane



pgsql-hackers by date:

Previous
From: Konstantin Knizhnik
Date:
Subject: Re: [HACKERS] [PATCH] Push limit to sort through a subquery
Next
From: Douglas Doole
Date:
Subject: Re: [HACKERS] [PATCH] Push limit to sort through a subquery