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: