On Wed, Nov 29, 2017 at 08:14:41PM -0800, Noah Misch wrote:
> 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.
Here's an implementation of (2). This is more intricate than I hoped. One
could argue for (1), but I estimate (2) wins by a nose. I successfully tested
http://strawberryperl.com/download/5.14.4.1/strawberry-perl-5.14.4.1-32bit.msi
(Perl 5.14.4; MinGW-built; must have -D_USE_32BIT_TIME_T) and
http://get.enterprisedb.com/languagepacks/edb-languagepack-10-3-windows.exe
(Perl 5.24.0; MSVC-built; must not have -D_USE_32BIT_TIME_T). I also tried
http://strawberryperl.com/download/5.8.9/strawberry-perl-5.8.9.5.msi, which
experienced a StackHash_0a9e crash during PERL_SYS_INIT3(), with or without
-D_USE_32BIT_TIME_T. I expect that breakage is orthogonal. I didn't have
ready access to obsolete MSVC-built Perl, so it will be interesting to see how
the buildfarm likes this.
