On 08/31/2012 01:10 PM, Dave Page wrote:
On Fri, Aug 31, 2012 at 5:51 PM, Andrew Dunstan <and...@dunslane.net> wrote:
On 08/31/2012 12:41 PM, Dave Page wrote:
On Fri, Aug 31, 2012 at 5:37 PM, Andrew Dunstan <and...@dunslane.net>
wrote:
On 08/31/2012 12:18 PM, Dave Page wrote:
On Fri, Aug 31, 2012 at 4:57 PM, Andrew Dunstan <and...@dunslane.net>
wrote:
On 08/31/2012 11:14 AM, Dave Page wrote:
On Fri, Aug 31, 2012 at 4:10 PM, Andrew Dunstan <and...@dunslane.net>
wrote:
On 08/31/2012 11:05 AM, Dave Page wrote:
I've added this to the release blockers section for 9.2 on the wiki,
as without it, pl/perl is unusable on Win32.
I'll have a look at it today.
Thanks Andrew - minor clarification; unusable on MSVC/Win32. I suspect
Mingw builds may be fine, as they use a much older runtime. Of course,
we've used MSVC++ for the installer builds for years now.
What exactly is the known combination of things that don't work, and
things
that do work? My only 32 bit test environment for this (ASPerl 5.12.2
build
1202 [293621], built Sep 6, 2010, Visual C++ Express 2008, Windows XP
SP3)
doesn't seem to have any problem building and running plperl. That
makes
it
tough to test if I don't know what exactly needs to change to break
things.
We're using VC++ 2010 Pro with ASPerl 5.14.2.1402 for 9.2, and VC++
2008 Pro with ASPerl 5.14.1.1401 at present. Our CM team have tried
multiple versions of Perl though, and seen the issue with 5.10 and
5.12 as well though. 5.8 seemed to be OK.
OK so from that I'm guessing the issue is probably VC++ 2010, which I
don't
have at all, let alone on a 32-bit machine :-(
Oh, well, I'll look and see if I feel comfortable about the patch anyway.
It's only 2010 for 9.2. We're using 2008 with 9.1, which also exhibits
the problem (see the bug report linked in my first post on this
thread).
Well, that makes things harder to diagnose. Why isn't my 2008 / ASPerl
5.12.2 setup exhibiting the problem?
No idea. Differences in the SDK perhaps? You're using VC++ Express
which (if memory serves) you have to download the SDK independently,
whereas we get a bundled, and possibly slightly different version with
the Pro edition.
As a side note - I'm not sure why _USE_32BIT_TIME_T was removed in the
first place; it was added specifically to avoid this sort of problem,
though iirc at the time we were thinking of extensions like Slony and
PostGIS being built with Mingw for use with the VC++ built server.
OK. Well, I didn't quite like the submitted patch for a couple of
reasons. First, it only affected VC2010 builds, and you said these
weren't the only ones affected. And second it didn't really highlight
what was being done.
So here are two patches, one for HEAD/9.2 and one for earlier releases,
that do this in a different way that is more obvious, and for all
versions of VC.
Please test. I will also test these.
cheers
andrew
diff --git a/src/tools/msvc/MSBuildProject.pm b/src/tools/msvc/MSBuildProject.pm
index ac99345..2e3eab6 100644
--- a/src/tools/msvc/MSBuildProject.pm
+++ b/src/tools/msvc/MSBuildProject.pm
@@ -61,16 +61,22 @@ EOF
print $f <<EOF;
</PropertyGroup>
EOF
+
+ # 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;' : '';
+
$self->WriteItemDefinitionGroup(
$f, 'Debug',
- { defs => '_DEBUG;DEBUG=1;',
+ { defs => "_DEBUG;DEBUG=1;$use_32bit_time_t",
opt => 'Disabled',
strpool => 'false',
runtime => 'MultiThreadedDebugDLL' });
$self->WriteItemDefinitionGroup(
$f,
'Release',
- { defs => '',
+ { defs => "$use_32bit_time_t",
opt => 'Full',
strpool => 'true',
runtime => 'MultiThreadedDLL' });
diff --git a/src/tools/msvc/VCBuildProject.pm b/src/tools/msvc/VCBuildProject.pm
index 1022329..6246826 100644
--- a/src/tools/msvc/VCBuildProject.pm
+++ b/src/tools/msvc/VCBuildProject.pm
@@ -32,9 +32,16 @@ sub WriteHeader
<Platforms><Platform Name="$self->{platform}"/></Platforms>
<Configurations>
EOF
+
+ # 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;' : '';
+
+
$self->WriteConfiguration(
$f, 'Debug',
- { defs => '_DEBUG;DEBUG=1;',
+ { defs => "_DEBUG;DEBUG=1;$use_32bit_time_t",
wholeopt => 0,
opt => 0,
strpool => 'false',
@@ -42,7 +49,7 @@ EOF
$self->WriteConfiguration(
$f,
'Release',
- { defs => '',
+ { defs => "$use_32bit_time_t",
wholeopt => 0,
opt => 3,
strpool => 'true',
diff --git a/src/tools/msvc/Project.pm b/src/tools/msvc/Project.pm
index 66752f9..ad62272 100644
--- a/src/tools/msvc/Project.pm
+++ b/src/tools/msvc/Project.pm
@@ -471,10 +471,23 @@ sub WriteHeader
<Platforms><Platform Name="$self->{platform}"/></Platforms>
<Configurations>
EOF
+ # 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;' : '';
+
$self->WriteConfiguration($f, 'Debug',
- { defs=>'_DEBUG;DEBUG=1;', wholeopt=>0, opt=>0, strpool=>'false', runtime=>3 });
+ { defs=>"_DEBUG;DEBUG=1;$use_32bit_time_t",
+ wholeopt=>0,
+ opt=>0,
+ strpool=>'false',
+ runtime=>3 });
$self->WriteConfiguration($f, 'Release',
- { defs=>'', wholeopt=>0, opt=>3, strpool=>'true', runtime=>2 });
+ { defs=> "$use_32bit_time_t",
+ wholeopt=>0,
+ opt=>3,
+ strpool=>'true',
+ runtime=>2 });
print $f <<EOF;
</Configurations>
EOF
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
