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.
regards, tom lane
