On Thu, Aug 10, 2017 at 8:30 AM, Ashutosh Sharma <ashu.coe...@gmail.com> wrote:
> So, the question is should we allow the preprocessor option
> '_USE_32BIT_TIME_T' to be defined implicitly or not in postgresql
> provided we are using Visual C compiler version > 8.0. I think this
> should make plperl compatible with perl binaries.
We've got this code in MSBuildProject.pm and VCBuildProject.pm:
# We have to use this flag on 32 bit targets because the 32bit perls
# are built with it and sometimes crash if we don't.
my $use_32bit_time_t =
$self->{platform} eq 'Win32' ? '_USE_32BIT_TIME_T;' : '';
Based on the discussion upthread, I think we now know that this was
not really the right approach. IIUC, a given 32-bit Perl might've
been built with _USE_32BIT_TIME_T, or not; in fact, given the comments
you found on the Perl side, it's more than likely that most modern
32-bit Perls are NOT build with this option. What we actually need to
do here is use _USE_32BIT_TIME_T if and only if it was used when Perl
was built (otherwise we'll end up with a different interpreter size).
The trouble with that is that _USE_32BIT_TIME_T also affects how
PostgreSQL code compiles. Apparently, given that according to Perl
this was changed by Microsoft in 2005, we're forcing the Microsoft
compilers into a non-default backward compatibility mode by defining
this symbol, and that affects how our entire code base compiles -- and
it just so happens that the result is compatible with older Perl
builds that used _USE_32BIT_TIME_T and not compatible with newer ones
that don't.
Maybe we need to make _USE_32BIT_TIME_T a compile-time configuration
option on Windows, and then cross-check that our setting is compatible
with Perl's setting.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
