On Sun, Oct 07, 2012 at 08:30:22PM +0200, Brar Piening wrote:
> Noah Misch wrote:
>> I'm marking this patch Waiting on Author, but the changes needed to
>> get it Ready for Committer are fairly trivial. Thanks, nm
>
> Thanks for your review and sorry for my delayed response - I've been on
> vacation.
>
> I'll look into adressing your comments and suggestions within the next
> few days.
Thanks. I decided to try a 32-bit build, but Solution::DeterminePlatform
detected it as x64. Its shibboleth is no longer valid; the cl.exe shipping
with VS 2012 Express for Desktop has a /favor option for both architectures:
32clhelp:/favor:<blend|ATOM> select processor to optimize for, one of:
64clhelp:/favor:<blend|AMD64|INTEL64|ATOM> select processor to optimize for,
one of:
Overlaying the first attached change fixed detection for this particular
compiler, but I have not checked compatibility with older versions. Do you
have VS 2008 and/or VS 2010 handy? Having worked around that, the build
eventually failed like this:
Creating library Debug\postgres\postgres.lib and object
Debug\postgres\postgres.exp
postgres.exp : error LNK2001: unresolved external symbol
_xmm@41f00000000000000000000000000000
[c:\cygwin\home\nm\src\pg\postgresql\postgres.vcxproj]
postgres.exp : error LNK2001: unresolved external symbol
_xmm@80000000000000008000000000000000
[c:\cygwin\home\nm\src\pg\postgresql\postgres.vcxproj]
postgres.exp : error LNK2001: unresolved external symbol
_xmm@80000000800000008000000080000000
[c:\cygwin\home\nm\src\pg\postgresql\postgres.vcxproj]
.\Debug\postgres\postgres.exe : fatal error LNK1120: 3 unresolved externals
[c:\cygwin\home\nm\src\pg\postgresql\postgres.vcxproj]
The command exited with code 1120.
Done executing task "Link" -- FAILED.
This compiler emits _xmm symbols automatically, where needed. The second
attached change lets the build complete and pass tests, but I can't readily
explain why it's necessary. In the 64-bit build, the _xmm symbols export
normally (albeit, I presume, needlessly). I hoped to find some rationale for
the preexisting gendef.pl exclusion of _real, which seems to resemble _xmm in
origin and use. Magnus/anyone, can you shed light on our exclusion of "_real"
symbols from .def files?
In any event, if these incremental changes seem sane to you, please merge them
into your next version.
nm
diff --git a/src/tools/msvc/Solution.pm b/src/tools/msvc/Solution.pm
index e51665c..218ca8d 100644
--- a/src/tools/msvc/Solution.pm
+++ b/src/tools/msvc/Solution.pm
@@ -63,13 +63,12 @@ sub DeterminePlatform
{
my $self = shift;
- # Determine if we are in 32 or 64-bit mode. Do this by seeing if CL has
- # 64-bit only parameters.
+ # Examine CL help output to determine if we are in 32 or 64-bit mode.
$self->{platform} = 'Win32';
- open(P, "cl /? 2>NUL|") || die "cl command not found";
+ open(P, "cl /? 2>&1 |") || die "cl command not found";
while (<P>)
{
- if (/^\/favor:</)
+ if (/for x64/)
{
$self->{platform} = 'x64';
last;
diff --git a/src/tools/msvc/gendef.pl b/src/tools/msvc/gendef.pl
index ab65c46..8ef0422 100644
--- a/src/tools/msvc/gendef.pl
+++ b/src/tools/msvc/gendef.pl
@@ -40,6 +40,7 @@ while (<$ARGV[0]/*.obj>)
next if $pieces[6] =~ /^\(/;
next if $pieces[6] =~ /^__real/;
next if $pieces[6] =~ /^__imp/;
+ next if $pieces[6] =~ /^__xmm/;
next if $pieces[6] =~ /NULL_THUNK_DATA$/;
next if $pieces[6] =~ /^__IMPORT_DESCRIPTOR/;
next if $pieces[6] =~ /^__NULL_IMPORT/;
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
