Re: pl/perl extension fails on Windows - Mailing list pgsql-hackers

On Thu, Aug 17, 2017 at 12:15:58PM -0400, Tom Lane wrote:
> 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".  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.)
> 
> Ah-hah: it wasn't ActiveState that fixed this at all; it was upstream
> Perl.  The stanza that Ashutosh found about defining _USE_32BIT_TIME_T
> originated in Perl 5.13.4; older Perls simply don't provide it, no
> matter how they were built.
> 
> We can now isolate the exact reason we're having trouble on baiji:
> it's building Postgres with MSVC 2005, which by default will think
> time_t is 64 bits, but it must be using a copy of Perl that was
> built with an older Microsoft compiler that doesn't think that.
> (Dave's "perl -V" output says ccversion='12.00.8804', but I don't
> know how to translate that to the marketing version.)  And since it's
> pre-5.13.4, Perl itself doesn't know it should advertise this fact.
> 
> So it's now looking to me like we should do the above with X = 5.13.4.
> That won't be a perfect solution, but it's about the best we can
> readily do.  Realistically, nobody out in the wider world is likely
> to care about building current PG releases against such old Perl
> versions on Windows; if we satisfy our older buildfarm critters,
> it's enough for me.

MinGW default behavior matches "cl -D_USE_32BIT_TIME_T", and MSVC >= 2005
default behavior matches "gcc -D__MINGW_USE_VC2005_COMPAT"[1].  MinGW-built
Perl[2] does not mention _USE_32BIT_TIME_T in $Config{ccflags}, so we
typically must add _USE_32BIT_TIME_T when using MSVC to build 32-bit against
MinGW-built Perl.  I'm considering two ways to achieve this:

1. If $Config{gccversion} is nonempty, add _USE_32BIT_TIME_T.  This will do  the wrong thing if MinGW changes its
defaultto match modern MSVC.  It will  do the wrong thing for a Perl built with "gcc -D__MINGW_USE_VC2005_COMPAT".
 

2. When configuring the build, determine whether to add _USE_32BIT_TIME_T by  running a test program built with and
withoutthat symbol.  Perhaps have  the test program store and retrieve a PL_modglobal value.  (PL_modglobal  maps to a
PerlInterpreterfield that follows the fields sensitive to  _USE_32BIT_TIME_T, and perlapi documents it since 5.8.0 or
earlier.) This  is more principled than (1), but it will be more code and may have weird  interactions with rare Perl
buildoptions.
 

I am inclined toward (2) if it takes no more than roughly a hundred lines of
code, else (1).  Opinions?  I regret investing in 32-bit Windows.  If there's
any OS where a 32-bit PostgreSQL server makes sense today, it's not Windows.


Ideally, $Config{ccflags} would include -D_USE_32BIT_TIME_T for MinGW-built
Perl, like it does for VC6-built Perl.  Considering Perl versions already in
the field, fixing Perl won't change this need to patch PostgreSQL.

Using MinGW to build a PostgreSQL that links to an MSVC-built Perl probably
requires -D__MINGW_USE_VC2005_COMPAT.  I may not bother for now.  We're less
likely to experience that, because Perl binaries advertised on perl.org or in
the PostgreSQL documentation are MinGW-built.


[1] https://gnunet.org/sorting-out-stat-thing

[2] ActivePerl has been MinGW-built for more than five years, and Strawberry
Perl has always been MinGW-built.  I'm guessing Ashutosh tested with an
MSVC-built Perl like
http://get.enterprisedb.com/languagepacks/edb-languagepack-10-3-windows.exe.