Re: Visual Studio 2012 RC - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: Visual Studio 2012 RC
Date
Msg-id 51048271.5030701@2ndQuadrant.com
Whole thread Raw
In response to Re: Visual Studio 2012 RC  (Craig Ringer <craig@2ndQuadrant.com>)
Responses Re: Visual Studio 2012 RC
List pgsql-hackers
On 01/27/2013 08:11 AM, Craig Ringer wrote:

> On my VS Express 2010 SP1:
> 
> Setting environment for using Microsoft Visual Studio 2010 x86 tools.
> 
> C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC>vcvarsall.bat /?
> Error in script usage. The correct usage is:
>     vcvarsall.bat [option]
> where [option] is: x86 | ia64 | amd64 | x86_amd64 | x86_ia64
> 
> For example:
>     vcvarsall.bat x86_ia64
> 
> C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC>vcvarsall.bat amd64
> The specified configuration type is missing.  The tools for the
> configuration might not be installed.
> 
> C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC>vcvarsall.bat
> x86_amd64
> The specified configuration type is missing.  The tools for the
> configuration might not be installed.
> 
> C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC>
>
>  If you have 64-bit compilers, either native or cross-compilers, for
> these tools then it's possible you've got them from a separate package
> such as an SDK update.
> 
> The only 64-bit compilers available on my test host are for VC Express
> 2012 (x86_amd64 cross-compiler) and Windows SDK 7.1 (native x64 compiler).

Further investigation suggests that they're there, but vcvarsall doesn't
recognise them.

The following cl.exe executables are present according to a "filename:
cl.exe" search in win7, omitting any with "ia64" in their path as
uninteresting (itanic):

"C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\cl.exe"

"C:\Program Files (x86)\Microsoft Visual Studio
11.0\VC\bin\x86_amd64\cl.exe"

"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\cl.exe"

"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\amd64\cl.exe"

"C:\Program Files (x86)\Microsoft Visual Studio
10.0\VC\bin\x86_amd64\cl.exe"

"C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\cl.exe"


Thus, clearly the 64-bit compilers for VC9 (2008) express are absent,
but those for VC 10 (2010) express are present, but not discovered by
vcvarsall.bat.

This is likely a consequence of the VC 2010 SP1 update removing the x64
compilers, then them being reinstalled by the VC 2010 SP1 x64 compiler
update. The vcvars scripts (vcvars64.bat) for these tools appear to be
missing.

The Windows SDK 7.1 SetEnv.cmd finds the x64 compilers installed by the
VC 2010 SP1 x64 compiler update fine, it's only VC's vcvarsall.bat that
doesn't.

If you have an original (non-SP1) VC 2010, you may have the x64
compilers and a working vcvars64.bat. I haven't checked and really don't
want to uninstall all the tools to reinstall and find out.

In the case of VC 2008 Express, it looks like you may be able to install
the x64 compilers by installing the Windows SDK for Windows Server 2008
and .NET Framework 3.5 (7.0); this won't provide integration with
vcvarsall.bat, but will work with its own "SetEnv.cmd /x64" script.

I think part of the confusion arises because the SDKs include compilers
from Visual Studio, but are not themselves Visual Studio (Express or
otherwise). For example, SDK 7.0 uses the VC 2008 compilers (cl 15), and
you can do x64 builds with them using the SDK's "setenv /x64", but not
using VC's "vcvarsall.bat amd64" or "vcvarsall.bat x86_amd64". You need
to install the standalone SDK to get the SDK SetEnv.bat; as far as I can
tell it doesn't seem to be included in the SDK installed bundled with VC.

To make things even more fun, with VC 2010 SP1 + x64 compiler pack and
no additional SDK installed you can do x64 builds with the VC 2010 SP1
x64 compiler pack by opening the project file and building in the GUI,
you just can't do it via vcvars and the command line because of the
missing vcvars64.bat.

Anyway, this is getting way off track. The point is that the MS SDKs and
compilers are a bit of a mess and that MinGW support is useful because
we can't rely on them continuing to offer free SDKs and compilers in future.



-- Craig Ringer                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: [PATCH] pg_isready (was: [WIP] pg_ping utility)
Next
From: Noah Misch
Date:
Subject: Re: Doc patch making firm recommendation for setting the value of commit_delay