From: Brar Piening <brar@gmx.de>
To: Noah Misch <noah@leadboat.com>
Cc: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Cc: Magnus Hagander <magnus@hagander.net>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Visual Studio 2012 RC
Date: Sun, 14 Oct 2012 23:34:54 +0200
Message-ID: <507B2FFE.2050905@gmx.de> (raw)
In-Reply-To: <20121008121128.GA2248@tornado.leadboat.com>
References: <4FCA84F6.5090706@gmx.de>
<CABUevEzT4B+MyM6-VH4_vvg1KFys4XAAKQcaKbbHRKH7mF7SSw@mail.gmail.com>
<4FD3F553.9060105@gmx.de>
<CABUevEwEYa8Ay5aK9kk+FPCWs6xiwnW-e1B2mcx3Ff3NMaBuhg@mail.gmail.com>
<4FEB0D39.6080108@enterprisedb.com>
<50526BA6.3030103@gmx.de>
<20121002011201.GC30396@tornado.leadboat.com>
<5071CA3E.5040509@gmx.de>
<20121008121128.GA2248@tornado.leadboat.com>
Noah Misch wrote:
> 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?
Older compilers work fine but localized ones will probably cause trouble
(for -> für in german).
I've decided to change the regex to "/^\/favor:<.+AMD64/" in my current
version of the patch as this is not very likely to appear in a 32-bit
environment and will not be subject ot localization problems.
> 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?
I kind of feel like excluding the _xmm symbols is the right thing to do
but - like you - I can't explain why they cause problems in a x86 build.
Regards,
Brar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: brar@gmx.de, noah@leadboat.com, heikki.linnakangas@enterprisedb.com, magnus@hagander.net
Subject: Re: Visual Studio 2012 RC
In-Reply-To: <507B2FFE.2050905@gmx.de>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox