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 default to 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 without that symbol. Perhaps have
the test program store and retrieve a PL_modglobal value. (PL_modglobal
maps to a PerlInterpreter field 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 build options.
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.
