Thread: Visual Studio 2012 RC
The attached patch makes postgres build with Visual Studio 2012 RC. As MS finally decided on the name I don't expect any need for changes for the final RTM. I didn't bother to update the docs for now as I still have some hope that the developer community succeds in pushig M$ to reverse this decision: http://people.planetpostgresql.org/andrew/index.php?/archives/276-Microsoft-throws-large-developer-communities-under-the-bus.html Regards, Brar
Attachment
On Sat, Jun 2, 2012 at 11:26 PM, Brar Piening <brar@gmx.de> wrote: > The attached patch makes postgres build with Visual Studio 2012 RC. Looks good in principle - please add it to the next commitfest (https://commitfest.postgresql.org/action/commitfest_view?id=14). We're definitely not adding a new build target post-beta for 9.2 :-) > As MS finally decided on the name I don't expect any need for changes for > the final RTM. > > I didn't bother to update the docs for now as I still have some hope that > the developer community succeds in pushig M$ to reverse this decision: > http://people.planetpostgresql.org/andrew/index.php?/archives/276-Microsoft-throws-large-developer-communities-under-the-bus.html We'll need docs by the time it should get committed of course - might as well write up something based on what we know now, and then update it if they change their behaviour. I don't have too much hope for them actually changing it - they seem hell-bent on forcing everybody into metro, and this seems to be yet another way to do that. But we can always hope... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On Sun, Jun 3, 2012 at 11:22 AM, Magnus Hagander <magnus@hagander.net> wrote: > On Sat, Jun 2, 2012 at 11:26 PM, Brar Piening <brar@gmx.de> wrote: >> The attached patch makes postgres build with Visual Studio 2012 RC. > > Looks good in principle - please add it to the next commitfest > (https://commitfest.postgresql.org/action/commitfest_view?id=14). > We're definitely not adding a new build target post-beta for 9.2 :-) > > >> As MS finally decided on the name I don't expect any need for changes for >> the final RTM. >> >> I didn't bother to update the docs for now as I still have some hope that >> the developer community succeds in pushig M$ to reverse this decision: >> http://people.planetpostgresql.org/andrew/index.php?/archives/276-Microsoft-throws-large-developer-communities-under-the-bus.html > > We'll need docs by the time it should get committed of course - might > as well write up something based on what we know now, and then update > it if they change their behaviour. > > I don't have too much hope for them actually changing it - they seem > hell-bent on forcing everybody into metro, and this seems to be yet > another way to do that. But we can always hope... Regardless, we should still add support for 2012 - we'll just need to note that Express cannot be used. FYI, we have to use Pro or higher to produce the installers as it is, otherwise we cannot distribute the runtimes. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Sun, Jun 3, 2012 at 12:37 PM, Dave Page <dpage@pgadmin.org> wrote: > On Sun, Jun 3, 2012 at 11:22 AM, Magnus Hagander <magnus@hagander.net> wrote: >> On Sat, Jun 2, 2012 at 11:26 PM, Brar Piening <brar@gmx.de> wrote: >>> The attached patch makes postgres build with Visual Studio 2012 RC. >> >> Looks good in principle - please add it to the next commitfest >> (https://commitfest.postgresql.org/action/commitfest_view?id=14). >> We're definitely not adding a new build target post-beta for 9.2 :-) >> >> >>> As MS finally decided on the name I don't expect any need for changes for >>> the final RTM. >>> >>> I didn't bother to update the docs for now as I still have some hope that >>> the developer community succeds in pushig M$ to reverse this decision: >>> http://people.planetpostgresql.org/andrew/index.php?/archives/276-Microsoft-throws-large-developer-communities-under-the-bus.html >> >> We'll need docs by the time it should get committed of course - might >> as well write up something based on what we know now, and then update >> it if they change their behaviour. >> >> I don't have too much hope for them actually changing it - they seem >> hell-bent on forcing everybody into metro, and this seems to be yet >> another way to do that. But we can always hope... > > Regardless, we should still add support for 2012 - we'll just need to > note that Express cannot be used. FYI, we have to use Pro or higher to > produce the installers as it is, otherwise we cannot distribute the > runtimes. Oh, absolutely, I agree with that. It goes to the docs. We might also want to think twice about producing the installers with 2012, and just stick to 2010 pro for that. Because once we go 2012 on that, it's no longer going ot be possible to build addons without either having the pro version or running into the risk of conflicting runtime versions... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On Sun, Jun 3, 2012 at 11:38 AM, Magnus Hagander <magnus@hagander.net> wrote: > > We might also want to think twice about producing the installers with > 2012, and just stick to 2010 pro for that. Because once we go 2012 on > that, it's no longer going ot be possible to build addons without > either having the pro version or running into the risk of conflicting > runtime versions... Right. That wouldn't happen until 9.4 at the earliest anyway - we build 2 branches per build machine, and have just setup a shiny new one for 9.2/9.3. My point being that we have time to see how badly things go for Microsoft with Metro, and see if they reverse their decisions to avoid destroying the company. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Magnus Hagander wrote: > I don't have too much hope for them actually changing it - they seem > hell-bent on forcing everybody into metro, and this seems to be yet > another way to do that. But we can always hope... Looks like they've learnt their lesson... http://blogs.msdn.com/b/visualstudio/archive/2012/06/08/visual-studio-express-2012-for-windows-desktop.aspx Regards, Brar
On Sunday, June 10, 2012, Brar Piening wrote:
Magnus Hagander wrote:I don't have too much hope for them actually changing it - they seem hell-bent on forcing everybody into metro, and this seems to be yet another way to do that. But we can always hope...
Looks like they've learnt their lesson...
http://blogs.msdn.com/b/visualstudio/archive/2012/06/08/visual-studio-express-2012-for-windows-
Yeah, though what I didn't realise was that 2012 won't target XP (and 2k3?). Urgh.
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Sun, Jun 10, 2012 at 3:16 AM, Brar Piening <brar@gmx.de> wrote: > Magnus Hagander wrote: >> >> I don't have too much hope for them actually changing it - they seem >> hell-bent on forcing everybody into metro, and this seems to be yet another >> way to do that. But we can always hope... > > > Looks like they've learnt their lesson... > > http://blogs.msdn.com/b/visualstudio/archive/2012/06/08/visual-studio-express-2012-for-windows-desktop.aspx Yeah. Didn't expect that to happen, but happy to see that it did! :-) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On 10.06.2012 11:41, Magnus Hagander wrote: > On Sun, Jun 10, 2012 at 3:16 AM, Brar Piening<brar@gmx.de> wrote: >> Magnus Hagander wrote: >>> >>> I don't have too much hope for them actually changing it - they seem >>> hell-bent on forcing everybody into metro, and this seems to be yet another >>> way to do that. But we can always hope... >> >> >> Looks like they've learnt their lesson... >> >> http://blogs.msdn.com/b/visualstudio/archive/2012/06/08/visual-studio-express-2012-for-windows-desktop.aspx > > Yeah. Didn't expect that to happen, but happy to see that it did! :-) I don't think we can realistically support VS2012 until Microsoft releases the gratis Visual Studio Express 2012 for Windows Desktop. We'll hardly find anyone willing to run a buildfarm machine with VS2012 until that, and I don't think any of the committers have access to VS2012 to test with. So, I'm bumping this to the next commitfest. By the time that begins, let's see if Microsoft has released it yet. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
Heikki Linnakangas wrote: > I don't think we can realistically support VS2012 until Microsoft > releases the gratis Visual Studio Express 2012 for Windows Desktop. As they've released now I've updated my Patch with docs and ask for review. Regards, Brar
Attachment
On Fri, Sep 14, 2012 at 01:26:30AM +0200, Brar Piening wrote:
> Heikki Linnakangas wrote:
>> I don't think we can realistically support VS2012 until Microsoft
>> releases the gratis Visual Studio Express 2012 for Windows Desktop.
>
> As they've released now I've updated my Patch with docs and ask for review.
I used this patch to build 64-bit PostgreSQL under Windows 7 Professional,
using Visual Studio 2012 Express for Windows Desktop. I did not provide a
config.pl, so this build used the defaults -- in particular, it did not
exercise linking to optional external projects like perl and libxml2. A
"vcregress check" passed. The build emitted no warnings beyond those seen on
buildfarm member "chough" (VS 2008 Express).
My build log filled 8.8 MiB, a large increase from the 432 KiB of the "chough"
build log. This isn't strictly a problem, but do you happen to have ideas for
curbing the noise?
I find no functional problems with the patch, but some comment updates and
other trivia need attention. The patch itself was reversed; it applied
cleanly with "patch -R". I regenerated it in the usual direction for the
portions I quote below.
src/tools/msvc/MSBuildProject.pm:4:# Package that encapsulates a MSBuild (Visual C++ 2010) project file
Say something like "Visual C++ 2010 or greater".
src/tools/msvc/VSObjectFactory.pm:93:# we use nmake as it has existed for a long time and still exists in visual
studio2010
Likewise, modify this comnent to be open-ended. If nmake ever disappears,
we'll be updating this code and can see to change the comment.
> *** a/doc/src/sgml/install-windows.sgml
> --- b/doc/src/sgml/install-windows.sgml
> ***************
> *** 22,28 ****
> Microsoft tools is to install a supported version of the
> <productname>Microsoft Windows SDK</productname> and use the included
> compiler. It is also possible to build with the full
> ! <productname>Microsoft Visual C++ 2005, 2008 or 2010</productname>. In some cases
> that requires the installation of the <productname>Windows SDK</productname>
> in addition to the compiler.
> </para>
> --- 22,28 ----
> Microsoft tools is to install a supported version of the
> <productname>Microsoft Windows SDK</productname> and use the included
> compiler. It is also possible to build with the full
> ! <productname>Microsoft Visual C++ 2005, 2008, 2010 or 2012</productname>. In some cases
> that requires the installation of the <productname>Windows SDK</productname>
> in addition to the compiler.
> </para>
I think this paragraph should be more like the one in the next patch hunk:
call out Visual Studio 2012 Express for Windows Desktop and Windows SDK 7.1 as
the main recommendations. Perhaps even demote the SDK entirely and just
recommend VS 2012. It'd odd to recommend only a past-version tool if a
current-version tool works just as well.
> ***************
> *** 77,90 ****
> <productname>Visual Studio Express</productname> or some versions of the
> <productname>Microsoft Windows SDK</productname>. If you do not already have a
> <productname>Visual Studio</productname> environment set up, the easiest
> ! way is to use the compilers in the <productname>Windows SDK</productname>,
> ! which is a free download from Microsoft.
> </para>
>
> <para>
> PostgreSQL is known to support compilation using the compilers shipped with
> <productname>Visual Studio 2005</productname> to
> ! <productname>Visual Studio 2010</productname> (including Express editions),
> as well as standalone Windows SDK releases 6.0 to 7.1.
> 64-bit PostgreSQL builds are only supported with
> <productname>Microsoft Windows SDK</productname> version 6.0a and above or
> --- 77,91 ----
> <productname>Visual Studio Express</productname> or some versions of the
> <productname>Microsoft Windows SDK</productname>. If you do not already have a
> <productname>Visual Studio</productname> environment set up, the easiest
> ! ways are to use the compilers in the <productname>Windows SDK</productname>
I would write "Windows SDK 7.1" here and remove the parenthesized bit.
There's a later mention of support for older versions.
> ! (<= 7.1) or those from <productname>Visual Studio Express 2012 for Windows
> ! Desktop</productname>, which are both free downloads from Microsoft.
> </para>
>
> <para>
> PostgreSQL is known to support compilation using the compilers shipped with
> <productname>Visual Studio 2005</productname> to
> ! <productname>Visual Studio 2012</productname> (including Express editions),
> as well as standalone Windows SDK releases 6.0 to 7.1.
> 64-bit PostgreSQL builds are only supported with
> <productname>Microsoft Windows SDK</productname> version 6.0a and above or
> ***************
> *** 157,162 **** $ENV{PATH}=$ENV{PATH} . ';c:\some\where\bison\bin';
> --- 158,165 ----
> If you install the <productname>Windows SDK</productname>
> including the <application>Visual C++ Compilers</application>,
> you don't need <productname>Visual Studio</productname> to build.
> + Note that as of Version 8.0a the Windows SDK no longer ships with a
> + complete command-line build environment.
The part ending here looks like this:
<varlistentry> <term><productname>Microsoft Windows SDK</productname></term> <listitem><para> It is
recommendedthat you upgrade to the latest supported version of the <productname>Microsoft Windows SDK</productname>
(currently version 7.1), available for download from <ulink url="http://www.microsoft.com/downloads/"></>.
</para> <para> You must always include the <application>Windows Headers and Libraries</application> part of
theSDK. If you install the <productname>Windows SDK</productname> including the <application>Visual C++
Compilers</application>, you don't need <productname>Visual Studio</productname> to build. Note that as of
Version8.0a the Windows SDK no longer ships with a complete command-line build environment. </para></listitem>
</varlistentry>
Since SDK version 7.1 is named as the "latest supported version", I understand
from that text that installing SDK version 8.0a along with compilers from
another source (VS 2012 full, VS 2012 Express for Desktop) is considered
"unsupported" as a PostgreSQL build environment. Is that your intent?
> *** a/src/tools/msvc/MSBuildProject.pm
> --- b/src/tools/msvc/MSBuildProject.pm
> ***************
> *** 397,400 **** sub new
> --- 397,440 ----
> return $self;
> }
>
> + package VC2012Project;
> +
> + #
> + # Package that encapsulates a Visual C++ 2012 project file
> + #
> +
> + use strict;
> + use warnings;
> + use base qw(MSBuildProject);
> +
> + sub new
> + {
> + my $classname = shift;
> + my $self = $classname->SUPER::_new(@_);
> + bless($self, $classname);
> +
> + $self->{vcver} = '11.00';
> +
> + return $self;
> + }
> +
> + sub WriteConfigurationPropertyGroup
Please add a comment explaining what this override does differently. (I think
it just adds the "<PlatformToolset>" element.)
> + {
> + my ($self, $f, $cfgname, $p) = @_;
> + my $cfgtype =
> + ($self->{type} eq "exe")
> + ?'Application'
> + :($self->{type} eq "dll"?'DynamicLibrary':'StaticLibrary');
> +
> + print $f <<EOF;
> + <PropertyGroup Condition="'\$(Configuration)|\$(Platform)'=='$cfgname|$self->{platform}'" Label="Configuration">
> + <ConfigurationType>$cfgtype</ConfigurationType>
> + <UseOfMfc>false</UseOfMfc>
> + <CharacterSet>MultiByte</CharacterSet>
> + <WholeProgramOptimization>$p->{wholeopt}</WholeProgramOptimization>
> + <PlatformToolset>v110</PlatformToolset>
> + </PropertyGroup>
> + EOF
> + }
> +
> 1;
I'm marking this patch Waiting on Author, but the changes needed to get it
Ready for Committer are fairly trivial.
Thanks,
nm
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. Regards, Brar
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
Attachment
One more thing -- I tried a build with NLS support and encountered this: src\backend\utils\adt\pg_locale.c(746): error C2039: 'lc_handle' : is not a member of 'threadlocaleinfostruct' [c:\cygwin\home\nm\src\pg\postgresql\postgres.vcxproj] That's in the function IsoLocaleName(), which digs around inside a locale_t. I suppose the (undocumented) content of that structure changed in this newer CRT (MSVCR110D). I apologize for the slow drip of problem reports; I just happen to be trying additional configurations with your patch as a foundation.
Noah Misch wrote: > I apologize for the slow drip of problem reports; I just happen to be trying > additional configurations with your patch as a foundation. No problem! I'm totally aware of the fact that testing the different platforms/configurations is pretty time consuming. Actually I didn't expect so many configuration dependent problems. Otherwise I'd have done more extensive testing myself. Anyways I'll be pretty busy until this weekend so I'll probably have a look at all the problems/suggestions at once by then. Regards, Brar
Noah Misch wrote: > My build log filled 8.8 MiB, a large increase from the 432 KiB of the "chough" > build log. This isn't strictly a problem, but do you happen to have ideas for > curbing the noise? Not yet. > I find no functional problems with the patch, but some comment updates and > other trivia need attention. The patch itself was reversed; it applied > cleanly with "patch -R". I regenerated it in the usual direction for the > portions I quote below. > > src/tools/msvc/MSBuildProject.pm:4:# Package that encapsulates a MSBuild (Visual C++ 2010) project file > > Say something like "Visual C++ 2010 or greater". > > src/tools/msvc/VSObjectFactory.pm:93:# we use nmake as it has existed for a long time and still exists in visual studio2010 > > Likewise, modify this comnent to be open-ended. If nmake ever disappears, > we'll be updating this code and can see to change the comment. fixed > > >> *** a/doc/src/sgml/install-windows.sgml >> --- b/doc/src/sgml/install-windows.sgml >> *************** >> *** 22,28 **** >> Microsoft tools is to install a supported version of the >> <productname>Microsoft Windows SDK</productname> and use the included >> compiler. It is also possible to build with the full >> ! <productname>Microsoft Visual C++ 2005, 2008 or 2010</productname>. In some cases >> that requires the installation of the <productname>Windows SDK</productname> >> in addition to the compiler. >> </para> >> --- 22,28 ---- >> Microsoft tools is to install a supported version of the >> <productname>Microsoft Windows SDK</productname> and use the included >> compiler. It is also possible to build with the full >> ! <productname>Microsoft Visual C++ 2005, 2008, 2010 or 2012</productname>. In some cases >> that requires the installation of the <productname>Windows SDK</productname> >> in addition to the compiler. >> </para> > I think this paragraph should be more like the one in the next patch hunk: > call out Visual Studio 2012 Express for Windows Desktop and Windows SDK 7.1 as > the main recommendations. Perhaps even demote the SDK entirely and just > recommend VS 2012. It'd odd to recommend only a past-version tool if a > current-version tool works just as well. fixed. > I would write "Windows SDK 7.1" here and remove the parenthesized bit. > There's a later mention of support for older versions. > >> ! (<= 7.1) or those from <productname>Visual Studio Express 2012 for Windows >> ! Desktop</productname>, which are both free downloads from Microsoft. fixed. > The part ending here looks like this: > > <varlistentry> > <term><productname>Microsoft Windows SDK</productname></term> > <listitem><para> > It is recommended that you upgrade to the latest supported version > of the <productname>Microsoft Windows SDK</productname> (currently > version 7.1), available for download from > <ulink url="http://www.microsoft.com/downloads/"></>. > </para> > <para> > You must always include the > <application>Windows Headers and Libraries</application> part of the SDK. > If you install the <productname>Windows SDK</productname> > including the <application>Visual C++ Compilers</application>, > you don't need <productname>Visual Studio</productname> to build. > Note that as of Version 8.0a the Windows SDK no longer ships with a > complete command-line build environment. > </para></listitem> > </varlistentry> > > Since SDK version 7.1 is named as the "latest supported version", I understand > from that text that installing SDK version 8.0a along with compilers from > another source (VS 2012 full, VS 2012 Express for Desktop) is considered > "unsupported" as a PostgreSQL build environment. Is that your intent? No, not really. What I want to say is that you'll need the SDK to build postgres. Using a Visual Studio version that ships with a supported SDK version (full versions of VS 2005 to 2010 as well as any version of VS 2012) will work. On the other hand standalone SDK versions that ship with compilers will also work. The major gotcha here is the fact that old sdk versions ship without compilers and old VS Express versions ship without SDK and you'll need both to build. I've tried to change the wording to make this more clear but perhaps someone else (native speaker) finds a better aproach to make this clear. > >> *** a/src/tools/msvc/MSBuildProject.pm >> --- b/src/tools/msvc/MSBuildProject.pm >> *************** >> *** 397,400 **** sub new >> --- 397,440 ---- >> return $self; >> } >> >> + package VC2012Project; >> + >> + # >> + # Package that encapsulates a Visual C++ 2012 project file >> + # >> + >> + use strict; >> + use warnings; >> + use base qw(MSBuildProject); >> + >> + sub new >> + { >> + my $classname = shift; >> + my $self = $classname->SUPER::_new(@_); >> + bless($self, $classname); >> + >> + $self->{vcver} = '11.00'; >> + >> + return $self; >> + } >> + >> + sub WriteConfigurationPropertyGroup > Please add a comment explaining what this override does differently. (I think > it just adds the "<PlatformToolset>" element.) done. Regards, Brar
Attachment
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
On Sun, Oct 14, 2012 at 11:13:46PM +0200, Brar Piening wrote: > Noah Misch wrote: >> Since SDK version 7.1 is named as the "latest supported version", I understand >> from that text that installing SDK version 8.0a along with compilers from >> another source (VS 2012 full, VS 2012 Express for Desktop) is considered >> "unsupported" as a PostgreSQL build environment. Is that your intent? > No, not really. > What I want to say is that you'll need the SDK to build postgres. > Using a Visual Studio version that ships with a supported SDK version > (full versions of VS 2005 to 2010 as well as any version of VS 2012) > will work. > On the other hand standalone SDK versions that ship with compilers will > also work. > The major gotcha here is the fact that old sdk versions ship without > compilers and old VS Express versions ship without SDK and you'll need > both to build. Thanks for clarifying. On Sun, Oct 14, 2012 at 11:34:54PM +0200, Brar Piening wrote: > 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. Good call. The only matter still requiring attention is a fix for IsoLocaleName().
Noah Misch wrote: > The only matter still requiring attention is a fix for IsoLocaleName(). Yep - I'll work on this and on some denoisifying of the build log files. Regards, Brar
On Mon, Oct 15, 2012 at 09:17:09PM +0200, Brar Piening wrote: > Noah Misch wrote: >> The only matter still requiring attention is a fix for IsoLocaleName(). >> > Yep - I'll work on this and on some denoisifying of the build log files. Great. Just to be clear, I consider the denoisification optional. Fixing IsoLocaleName(), however, is essential.
Noah Misch wrote: > On Mon, Oct 15, 2012 at 09:17:09PM +0200, Brar Piening wrote: > > Noah Misch wrote: > >> The only matter still requiring attention is a fix for IsoLocaleName(). > >> > > Yep - I'll work on this and on some denoisifying of the build log files. > > Great. Just to be clear, I consider the denoisification optional. Fixing > IsoLocaleName(), however, is essential. There having been no updated patch yet, I have closed this as returned with feedback. Thanks Noah! Please make sure to submit an updated patch to the upcoming commitfest, which is due to start in about three weeks. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Alvaro Herrera wrote: > There having been no updated patch yet, I have closed this as returned > with feedback. Thanks Noah! > > Please make sure to submit an updated patch to the upcoming commitfest, > which is due to start in about three weeks. Due to an hyperacute increase of workload in my day job I currently can't promise anything. Sorry! Brar
On Mon, Oct 15, 2012 at 07:53:51AM -0400, Noah Misch wrote: > The only matter still requiring attention is a fix for IsoLocaleName(). Following off-list coordination with Brar, I went about finishing up this patch. The above problem proved deeper than expected. For Windows Vista, Microsoft made RFC 4646 tags the preferred way to denote a locale in Windows. Microsoft calls them "locale names". Starting with Visual Studio 2012, setlocale() accepts locale names in addition to all the things it previously accepted. One can now use things like "initdb --locale=zh-CN" and "CREATE DATABASE foo LC_CTYPE = 'pl'". This meant updating win32_langinfo() and find_matching_ts_config() to handle the new formats. In passing, I fixed an unchecked malloc() in win32_langinfo(). In addition to expanding the set of valid locale inputs, VS2012 changes the (undocumented) content of _locale_t to hold locale names where it previously held locale identifiers. I taught IsoLocaleName() to handle the new material. I also sought to improve the comments on IsoLocaleName(); its significance was not previously clear to me. This thread has some background: http://archives.postgresql.org/message-id/4964B45E.5080003@hagander.net Though I'm not entirely sanguine about digging into the officially-opaque _locale_t, we have been doing it that way for several years. None of the alternatives are clearly-satisfying. In particular, I found no good way to look up the code page corresponding to a locale name on pre-Vista systems. The CRT itself handles this by translating locale names to locale identifiers using a lookup table. The Gnulib "localename" and "setlocale" modules are also interesting studies on the topic. In previous reviews, I missed the need to update pgwin32_putenv(). The addition of VS2010 support had also missed it, so this catches up. That function has other problems, but I will hold them for another patch. Tester warning: if you currently have some form of VS2010 installed, including the compilers of Windows SDK 7.1, beware of this problem: http://stackoverflow.com/questions/10888391/link-fatal-error-lnk1123-failure-during-conversion-to-coff-file-invalid-or-c Thanks, nm
Attachment
<div class="moz-cite-prefix">On 01/01/2013 10:54 AM, Noah Misch wrote:<br /></div><blockquote cite="mid:20130101025421.GA17763@tornado.leadboat.com"type="cite"><pre wrap="">On Mon, Oct 15, 2012 at 07:53:51AM -0400,Noah Misch wrote: </pre><blockquote type="cite"><pre wrap="">The only matter still requiring attention is a fix for IsoLocaleName(). </pre></blockquote><pre wrap=""> Following off-list coordination with Brar, I went about finishing up this patch. The above problem proved deeper than expected. For Windows Vista, Microsoft made RFC 4646 tags the preferred way to denote a locale in Windows. Microsoft calls them "locale names". Starting with Visual Studio 2012, setlocale() accepts locale names in addition to all the things it previously accepted. One can now use things like "initdb --locale=zh-CN" and "CREATE DATABASE foo LC_CTYPE = 'pl'". This meant updating win32_langinfo() and find_matching_ts_config() to handle the new formats. In passing, I fixed an unchecked malloc() in win32_langinfo(). In addition to expanding the set of valid locale inputs, VS2012 changes the (undocumented) content of _locale_t to hold locale names where it previously held locale identifiers. I taught IsoLocaleName() to handle the new material. I also sought to improve the comments on IsoLocaleName(); its significance was not previously clear to me. This thread has some background: <a class="moz-txt-link-freetext" href="http://archives.postgresql.org/message-id/4964B45E.5080003@hagander.net">http://archives.postgresql.org/message-id/4964B45E.5080003@hagander.net</a> Though I'm not entirely sanguine about digging into the officially-opaque _locale_t, we have been doing it that way for several years. None of the alternatives are clearly-satisfying. In particular, I found no good way to look up the code page corresponding to a locale name on pre-Vista systems. The CRT itself handles this by translating locale names to locale identifiers using a lookup table. The Gnulib "localename" and "setlocale" modules are also interesting studies on the topic. In previous reviews, I missed the need to update pgwin32_putenv(). The addition of VS2010 support had also missed it, so this catches up. That function has other problems, but I will hold them for another patch. Tester warning: if you currently have some form of VS2010 installed, including the compilers of Windows SDK 7.1, beware of this problem: <a class="moz-txt-link-freetext" href="http://stackoverflow.com/questions/10888391/link-fatal-error-lnk1123-failure-during-conversion-to-coff-file-invalid-or-c">http://stackoverflow.com/questions/10888391/link-fatal-error-lnk1123-failure-during-conversion-to-coff-file-invalid-or-c</a> </pre></blockquote> FYI, you can properly fix this without uninstalling anything, giving you a system with a working VS 2012as well as working SDK 7.1 / VS 2010 SP1 32-bit and 64-bit compilers.<br /><br /> Install the tools in the followingorder:<br /><br /> * VS Express 2010: <a class="moz-txt-link-freetext" href="http://www.microsoft.com/visualstudio/eng/products/visual-studio-2010-express">http://www.microsoft.com/visualstudio/eng/products/visual-studio-2010-express</a><br />* Windows SDK 7.1<br /> * VS 2010 SP1: <a class="moz-txt-link-freetext" href="http://www.microsoft.com/en-au/download/details.aspx?id=23691">http://www.microsoft.com/en-au/download/details.aspx?id=23691</a><br />* VS 2010 SP1 Compiler Update: <a class="moz-txt-link-freetext" href="http://www.microsoft.com/en-au/download/details.aspx?id=4422">http://www.microsoft.com/en-au/download/details.aspx?id=4422</a><br />* VS Express 2012<br /><br /> Note that SDK 7.1 and VS 2010 will fail to install if you have a newer version of the Visualc++ 2010 runtime installed. Newer programs often install this for you. As a workaround, you must uninstall the newerruntime, install Visual Studio, the SDK, and service pack, then reinstall the newer runtime to get the programs thatrequire it to work again.<br /><br /> I've written more about both of these in the TROUBLESHOOTING section of <a href="https://github.com/2ndQuadrant/pg_build_win/blob/master/README.md">https://github.com/2ndQuadrant/pg_build_win/blob/master/README.md</a><br /><br/><pre class="moz-signature" cols="72">-- Craig Ringer <a class="moz-txt-link-freetext" href="http://www.2ndQuadrant.com/">http://www.2ndQuadrant.com/</a>PostgreSQLDevelopment, 24x7 Support, Training & Services</pre>
On Mon, Jan 21, 2013 at 05:32:37PM +0800, Craig Ringer wrote: > On 01/01/2013 10:54 AM, Noah Misch wrote: > > Tester warning: if you currently have some form of VS2010 installed, including > > the compilers of Windows SDK 7.1, beware of this problem: > > http://stackoverflow.com/questions/10888391/link-fatal-error-lnk1123-failure-during-conversion-to-coff-file-invalid-or-c > FYI, you can properly fix this without uninstalling anything, giving you > a system with a working VS 2012 as well as working SDK 7.1 / VS 2010 SP1 > 32-bit and 64-bit compilers. > > Install the tools in the following order: > > * VS Express 2010: > http://www.microsoft.com/visualstudio/eng/products/visual-studio-2010-express > * Windows SDK 7.1 > * VS 2010 SP1: http://www.microsoft.com/en-au/download/details.aspx?id=23691 > * VS 2010 SP1 Compiler Update: > http://www.microsoft.com/en-au/download/details.aspx?id=4422 > * VS Express 2012 > > Note that SDK 7.1 and VS 2010 will fail to install if you have a newer > version of the Visual c++ 2010 runtime installed. Newer programs often > install this for you. As a workaround, you must uninstall the newer > runtime, install Visual Studio, the SDK, and service pack, then > reinstall the newer runtime to get the programs that require it to work > again. > > I've written more about both of these in the TROUBLESHOOTING section of > https://github.com/2ndQuadrant/pg_build_win/blob/master/README.md What fun. Thanks for working that out.
On 01/21/2013 07:23 PM, Noah Misch wrote: > What fun. Thanks for working that out. It's made even more fun by Microsoft's answer to "how do I silent-install the VS 2012 SP1 compiler update" - you don't. Yeah, it's great. -- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
On 01/21/2013 04:32 AM, Craig Ringer wrote: > On 01/01/2013 10:54 AM, Noah Misch wrote: >> On Mon, Oct 15, 2012 at 07:53:51AM -0400, Noah Misch wrote: >>> The only matter still requiring attention is a fix for IsoLocaleName(). >> Following off-list coordination with Brar, I went about finishing up this >> patch. The above problem proved deeper than expected. For Windows Vista, >> Microsoft made RFC 4646 tags the preferred way to denote a locale in Windows. >> Microsoft calls them "locale names". Starting with Visual Studio 2012, >> setlocale() accepts locale names in addition to all the things it previously >> accepted. One can now use things like "initdb --locale=zh-CN" and "CREATE >> DATABASE foo LC_CTYPE = 'pl'". This meant updating win32_langinfo() and >> find_matching_ts_config() to handle the new formats. In passing, I fixed an >> unchecked malloc() in win32_langinfo(). >> >> In addition to expanding the set of valid locale inputs, VS2012 changes the >> (undocumented) content of _locale_t to hold locale names where it previously >> held locale identifiers. I taught IsoLocaleName() to handle the new material. >> I also sought to improve the comments on IsoLocaleName(); its significance was >> not previously clear to me. This thread has some background: >> http://archives.postgresql.org/message-id/4964B45E.5080003@hagander.net >> >> Though I'm not entirely sanguine about digging into the officially-opaque >> _locale_t, we have been doing it that way for several years. None of the >> alternatives are clearly-satisfying. In particular, I found no good way to >> look up the code page corresponding to a locale name on pre-Vista systems. >> The CRT itself handles this by translating locale names to locale identifiers >> using a lookup table. The Gnulib "localename" and "setlocale" modules are >> also interesting studies on the topic. >> >> In previous reviews, I missed the need to update pgwin32_putenv(). The >> addition of VS2010 support had also missed it, so this catches up. That >> function has other problems, but I will hold them for another patch. >> >> Tester warning: if you currently have some form of VS2010 installed, including >> the compilers of Windows SDK 7.1, beware of this problem: >> http://stackoverflow.com/questions/10888391/link-fatal-error-lnk1123-failure-during-conversion-to-coff-file-invalid-or-c > FYI, you can properly fix this without uninstalling anything, giving > you a system with a working VS 2012 as well as working SDK 7.1 / VS > 2010 SP1 32-bit and 64-bit compilers. > > Install the tools in the following order: > > * VS Express 2010: > http://www.microsoft.com/visualstudio/eng/products/visual-studio-2010-express > * Windows SDK 7.1 > * VS 2010 SP1: > http://www.microsoft.com/en-au/download/details.aspx?id=23691 > * VS 2010 SP1 Compiler Update: > http://www.microsoft.com/en-au/download/details.aspx?id=4422 > * VS Express 2012 > > Note that SDK 7.1 and VS 2010 will fail to install if you have a newer > version of the Visual c++ 2010 runtime installed. Newer programs often > install this for you. As a workaround, you must uninstall the newer > runtime, install Visual Studio, the SDK, and service pack, then > reinstall the newer runtime to get the programs that require it to > work again. > > I've written more about both of these in the TROUBLESHOOTING section > of https://github.com/2ndQuadrant/pg_build_win/blob/master/README.md > That's useful information, which should perhaps be put somewhere more obvious for people to find, like the wiki. I realise you're doing a lot of stuff, but you seem to be ahead of just about everyone (including me and I suspect Magnus) on this, so maybe you could take a peek at this patch? cheers andrew
<div class="moz-cite-prefix">On 01/21/2013 08:44 PM, Andrew Dunstan wrote:<br /></div><blockquote cite="mid:50FD3840.8010700@dunslane.net"type="cite"><br /> On 01/21/2013 04:32 AM, Craig Ringer wrote: <br /><blockquotetype="cite">On 01/01/2013 10:54 AM, Noah Misch wrote: <br /><blockquote type="cite">On Mon, Oct 15, 2012 at07:53:51AM -0400, Noah Misch wrote: <br /><blockquote type="cite">The only matter still requiring attention is a fix forIsoLocaleName(). <br /></blockquote> Following off-list coordination with Brar, I went about finishing up this <br />patch. The above problem proved deeper than expected. For Windows Vista, <br /> Microsoft made RFC 4646 tags the preferredway to denote a locale in Windows. <br /> Microsoft calls them "locale names". Starting with Visual Studio 2012,<br /> setlocale() accepts locale names in addition to all the things it previously <br /> accepted. One can now usethings like "initdb --locale=zh-CN" and "CREATE <br /> DATABASE foo LC_CTYPE = 'pl'". This meant updating win32_langinfo()and <br /> find_matching_ts_config() to handle the new formats. In passing, I fixed an <br /> uncheckedmalloc() in win32_langinfo(). <br /><br /> In addition to expanding the set of valid locale inputs, VS2012 changesthe <br /> (undocumented) content of _locale_t to hold locale names where it previously <br /> held locale identifiers. I taught IsoLocaleName() to handle the new material. <br /> I also sought to improve the comments on IsoLocaleName();its significance was <br /> not previously clear to me. This thread has some background: <br /><a class="moz-txt-link-freetext" href="http://archives.postgresql.org/message-id/4964B45E.5080003@hagander.net">http://archives.postgresql.org/message-id/4964B45E.5080003@hagander.net</a><br /><br/> Though I'm not entirely sanguine about digging into the officially-opaque <br /> _locale_t, we have been doing itthat way for several years. None of the <br /> alternatives are clearly-satisfying. In particular, I found no good wayto <br /> look up the code page corresponding to a locale name on pre-Vista systems. <br /> The CRT itself handles thisby translating locale names to locale identifiers <br /> using a lookup table. The Gnulib "localename" and "setlocale"modules are <br /> also interesting studies on the topic. <br /><br /> In previous reviews, I missed the needto update pgwin32_putenv(). The <br /> addition of VS2010 support had also missed it, so this catches up. That <br/> function has other problems, but I will hold them for another patch. <br /><br /> Tester warning: if you currentlyhave some form of VS2010 installed, including <br /> the compilers of Windows SDK 7.1, beware of this problem: <br/><a class="moz-txt-link-freetext" href="http://stackoverflow.com/questions/10888391/link-fatal-error-lnk1123-failure-during-conversion-to-coff-file-invalid-or-c">http://stackoverflow.com/questions/10888391/link-fatal-error-lnk1123-failure-during-conversion-to-coff-file-invalid-or-c</a><br /></blockquote>FYI, you can properly fix this without uninstalling anything, giving you a system with a working VS 2012 aswell as working SDK 7.1 / VS 2010 SP1 32-bit and 64-bit compilers. <br /><br /> Install the tools in the following order:<br /><br /> * VS Express 2010: <a class="moz-txt-link-freetext" href="http://www.microsoft.com/visualstudio/eng/products/visual-studio-2010-express">http://www.microsoft.com/visualstudio/eng/products/visual-studio-2010-express</a><br />* Windows SDK 7.1 <br /> * VS 2010 SP1: <a class="moz-txt-link-freetext" href="http://www.microsoft.com/en-au/download/details.aspx?id=23691">http://www.microsoft.com/en-au/download/details.aspx?id=23691</a><br />* VS 2010 SP1 Compiler Update: <a class="moz-txt-link-freetext" href="http://www.microsoft.com/en-au/download/details.aspx?id=4422">http://www.microsoft.com/en-au/download/details.aspx?id=4422</a><br />* VS Express 2012 <br /><br /> Note that SDK 7.1 and VS 2010 will fail to install if you have a newer version of the Visualc++ 2010 runtime installed. Newer programs often install this for you. As a workaround, you must uninstall the newerruntime, install Visual Studio, the SDK, and service pack, then reinstall the newer runtime to get the programs thatrequire it to work again. <br /><br /> I've written more about both of these in the TROUBLESHOOTING section of <a class="moz-txt-link-freetext" href="https://github.com/2ndQuadrant/pg_build_win/blob/master/README.md">https://github.com/2ndQuadrant/pg_build_win/blob/master/README.md</a><br /><br/></blockquote><br /> That's useful information, which should perhaps be put somewhere more obvious for people to find,like the wiki. <br /><br /> I realise you're doing a lot of stuff, but you seem to be ahead of just about everyone (includingme and I suspect Magnus) on this, so maybe you could take a peek at this patch?<br /></blockquote><br /> It's buildingon my Jenkins instance at the moment, to make sure it doesn't break VS 2010 / Windows SDK 7.1 . I've merged it intoHEAD and pushed to <a href="https://github.com/ringerc/postgres/tree/vs2012">https://github.com/ringerc/postgres/tree/vs2012</a>;the only conflictwas a trivial one in the docs.<br /><br /><pre class="moz-signature" cols="72">-- Craig Ringer <a class="moz-txt-link-freetext" href="http://www.2ndQuadrant.com/">http://www.2ndQuadrant.com/</a>PostgreSQL Development,24x7 Support, Training & Services</pre>
<div class="moz-cite-prefix">On 01/21/2013 09:06 PM, Craig Ringer wrote:<br /><br /></div><blockquote cite="mid:50FD3D5B.9040506@2ndQuadrant.com"type="cite"> It's building on my Jenkins instance at the moment, to make sureit doesn't break VS 2010 / Windows SDK 7.1 . I've merged it into HEAD and pushed to <a href="https://github.com/ringerc/postgres/tree/vs2012" moz-do-not-send="true">https://github.com/ringerc/postgres/tree/vs2012</a>;the only conflict was a trivial one in the docs.<br/></blockquote><br /> A quick update: No breakage of WinSDK 7.1 / VS 2010 was found.<br /><br /> I'm having to domore work than I'd hoped to set up my build env for VS 2012 properly and update the build wrapper to handle it so VS 2012testing is still in progress. Expect a report in a few hours.<br /><pre class="moz-signature" cols="72">-- Craig Ringer <a class="moz-txt-link-freetext" href="http://www.2ndQuadrant.com/">http://www.2ndQuadrant.com/</a>PostgreSQLDevelopment, 24x7 Support, Training & Services</pre>
<div class="moz-cite-prefix">On 01/23/2013 02:14 PM, Craig Ringer wrote:<br /></div><blockquote cite="mid:50FF7FD0.7050705@2ndQuadrant.com"type="cite"><div class="moz-cite-prefix">On 01/21/2013 09:06 PM, Craig Ringerwrote:<br /><br /></div><blockquote cite="mid:50FD3D5B.9040506@2ndQuadrant.com" type="cite"> It's building on my Jenkinsinstance at the moment, to make sure it doesn't break VS 2010 / Windows SDK 7.1 . I've merged it into HEAD and pushedto <a href="https://github.com/ringerc/postgres/tree/vs2012" moz-do-not-send="true">https://github.com/ringerc/postgres/tree/vs2012</a>;the only conflict was a trivial one in the docs.<br/></blockquote><br /> A quick update: No breakage of WinSDK 7.1 / VS 2010 was found.<br /><br /> I'm having to domore work than I'd hoped to set up my build env for VS 2012 properly and update the build wrapper to handle it so VS 2012testing is still in progress. Expect a report in a few hours.<br /></blockquote> No go on VS 2012 yet.<br /><br /> Whenbuilding a tree with your patch applied using VS 2012 Express via a command line environment set up with:<br /><br /> "c:\program files (x86)\Microsoft Visual Studio 11.0\VC\vcvarsall.bat" x86<br /><br /> which is the same as the "32-bitbuild tools" Start menu entry, the build fails with:<br /><br /><br /> C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.Targets(518,5):error MSB8008: Specified platform toolset(v110) is not installed or invalid. Please make sure that a supported PlatformToolset value is selected. [c:\pg\postgresql\sdk8.0_cl17_vs11.0\x86\Release\vs2012\postgres.vcxproj]<br/><br /><br /> In case it's relevant, the MicrosoftSDK for Windows 8 is installed on this machine and appears to have been detected, as WindowsSdkDir has been setto C:\Program Files (x86)\Windows Kits\8.0\ .<br /><br /> I haven't explicitly set PlatformToolset in the environment.<br/><br /> The machine also has Visual Studio 2010 Express SP1 and the Microsoft Windows SDK 7.1 with VS SP1and VS SP1 compiler update on it. All work fine.<br /><br /> "where msbuild" reports:<br /><br /> c:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe<br/> c:\Windows\Microsoft.NET\Framework64\v3.5\MSBuild.exe<br/><br /> and "msbuild" reports:<br /><br /> Microsoft (R) BuildEngine version 4.0.30319.17929<br /> [Microsoft .NET Framework, version 4.0.30319.17929]<br /> Copyright (C)Microsoft Corporation. All rights reserved.<br /><br /> "cl" reports:<br /><br /> Microsoft (R) C/C++ Optimizing CompilerVersion 17.00.50727.1 for x86<br /> Copyright (C) Microsoft Corporation. All rights reserved.<br /><br /> usage: cl [ option... ] filename... [ /link linkoption... ]<br /><br /> The host is a 64-bit Windows 7 machine.<br /><br/> Error detail:<br /><br /><br /> "c:\pg\postgresql\sdk8.0_cl17_vs11.0\x86\Release\vs2012\pgsql.sln" (default target)(1) -><br /> "c:\pg\postgresql\sdk8.0_cl17_vs11.0\x86\Release\vs2012\postgres.vcxproj" (default target) (2) -><br/> (PlatformPrepareForBuild target) -> <br /> C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.Targets(518,5):error MSB8008: Specified platform toolset(v110) is not installed or invalid. Please make sure that a supported PlatformToolset value is selected. [c:\pg\postgresql\sdk8.0_cl17_vs11.0\x86\Release\vs2012\postgres.vcxproj]<br/><br /><br /> "c:\pg\postgresql\sdk8.0_cl17_vs11.0\x86\Release\vs2012\pgsql.sln"(default target) (1) -><br /> "c:\pg\postgresql\sdk8.0_cl17_vs11.0\x86\Release\vs2012\libpqwalreceiver.vcxproj"(default target) (4) -><br /> "c:\pg\postgresql\sdk8.0_cl17_vs11.0\x86\Release\vs2012\libpq.vcxproj"(default target) (5) -><br /> "c:\pg\postgresql\sdk8.0_cl17_vs11.0\x86\Release\vs2012\libpgport.vcxproj"(default target) (6) -><br /> C:\Program Files(x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.Targets(518,5): error MSB8008: Specified platformtoolset (v110) is not installed or invalid. Please make sure that a supported PlatformToolset value is selected.[c:\pg\postgresql\sdk8.0_cl17_vs11.0\x86\Release\vs2012\libpgport.vcxproj]<br /><br /><br /> "c:\pg\postgresql\sdk8.0_cl17_vs11.0\x86\Release\vs2012\pgsql.sln"(default target) (1) -><br /> "c:\pg\postgresql\sdk8.0_cl17_vs11.0\x86\Release\vs2012\pgevent.vcxproj"(default target) (14) -><br /> C:\Program Files(x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.Targets(518,5): error MSB8008: Specified platformtoolset (v110) is not installed or invalid. Please make sure that a supported PlatformToolset value is selected.[c:\pg\postgresql\sdk8.0_cl17_vs11.0\x86\Release\vs2012\pgevent.vcxproj]<br /><br /><br /> Thoughts?<br /><br />How have you been testing VS2012 builds? In what environment?<br /><pre class="moz-signature" cols="72">-- Craig Ringer <a class="moz-txt-link-freetext" href="http://www.2ndQuadrant.com/">http://www.2ndQuadrant.com/</a>PostgreSQLDevelopment, 24x7 Support, Training & Services</pre>
<blockquote cite="mid:50FF897B.2050603@2ndQuadrant.com" type="cite"><div class="moz-cite-prefix">On 01/23/2013 02:14 PM,Craig Ringer wrote:<br /></div><br /> How have you been testing VS2012 builds? In what environment?<br /></blockquote><br/> When I tested this patch the last time I've been using Windows 8 RTM (Microsoft Windows 8 EnterpriseEvaluation - 6.2.9200 Build 9200) and Microsoft Visual Studio Express 2012 für Windows Desktop RTM (Version 11.0.50727.42)<br/><br /> Regards,<br /><br /> Brar<br />
<div class="moz-cite-prefix">On 01/24/2013 03:23 AM, Brar Piening wrote:<br /></div><blockquote
cite="mid:510038B4.5090101@gmx.de"type="cite"><blockquote cite="mid:50FF897B.2050603@2ndQuadrant.com" type="cite"><div
class="moz-cite-prefix">On01/23/2013 02:14 PM, Craig Ringer wrote:<br /></div><br /> How have you been testing VS2012
builds?In what environment?<br /></blockquote><br /> When I tested this patch the last time I've been using Windows 8
RTM(Microsoft Windows 8 Enterprise Evaluation - 6.2.9200 Build 9200) and Microsoft Visual Studio Express 2012 für
WindowsDesktop RTM (Version 11.0.50727.42)<br /></blockquote><br /> ... and how are you setting up your build
environment?Can you show the steps you're following to get a successful build using this patch?<br /><br /> If you
installthe Windows 8 SDK, do you encounter issues?<br /><pre class="moz-signature" cols="72">-- Craig Ringer
<a class="moz-txt-link-freetext" href="http://www.2ndQuadrant.com/">http://www.2ndQuadrant.com/</a>PostgreSQL
Development,24x7 Support, Training & Services</pre>
Hi Craig, Thanks for testing. On Wed, Jan 23, 2013 at 02:55:55PM +0800, Craig Ringer wrote: > When building a tree with your patch applied using VS 2012 Express via a > command line environment set up with: > > "c:\program files (x86)\Microsoft Visual Studio > 11.0\VC\vcvarsall.bat" x86 Likewise. > which is the same as the "32-bit build tools" Start menu entry, the > build fails with: > > > C:\Program Files > (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.Targets(518,5): > error MSB8008: Specified platform toolset (v110) is not installed or > invalid. Please make sure that a supported PlatformToolset value is > selected. > [c:\pg\postgresql\sdk8.0_cl17_vs11.0\x86\Release\vs2012\postgres.vcxproj] > > > In case it's relevant, the Microsoft SDK for Windows 8 is installed on > this machine and appears to have been detected, as WindowsSdkDir has > been set to C:\Program Files (x86)\Windows Kits\8.0\ . My WindowsSdkDir was the same. I had not manually installed the SDK; I suppose it was installed as part of Visual Studio Express 2012 for Windows Desktop. I tried manually installing Windows SDK 8.59.29750, and the build still worked fine. > I haven't explicitly set PlatformToolset in the environment. > > The machine also has Visual Studio 2010 Express SP1 and the Microsoft > Windows SDK 7.1 with VS SP1 and VS SP1 compiler update on it. All work fine. > > "where msbuild" reports: > > c:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe > c:\Windows\Microsoft.NET\Framework64\v3.5\MSBuild.exe Mine are found in Framework, not Framework64: C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe C:\Windows\Microsoft.NET\Framework\v3.5\MSBuild.exe If I prepend Framework64 to my path, the build does fail, albeit not the same way your build fails: d:\cygwin\home\nm\src\pg\postgresql\postgres.vcxproj(16,3): error MSB4019: The imported project "d:\Microsoft.Cpp.Default.props"was not found. Confirm that the path in the <Import> declaration is correct, and that thefile exists on disk. > and "msbuild" reports: > > Microsoft (R) Build Engine version 4.0.30319.17929 > [Microsoft .NET Framework, version 4.0.30319.17929] > Copyright (C) Microsoft Corporation. All rights reserved. Identical: Microsoft (R) Build Engine version 4.0.30319.17929 [Microsoft .NET Framework, version 4.0.30319.17929] Copyright (C) Microsoft Corporation. All rights reserved. > "cl" reports: > > Microsoft (R) C/C++ Optimizing Compiler Version 17.00.50727.1 for x86 > Copyright (C) Microsoft Corporation. All rights reserved. > > usage: cl [ option... ] filename... [ /link linkoption... ] Identical: Microsoft (R) C/C++ Optimizing Compiler Version 17.00.50727.1 for x86 Copyright (C) Microsoft Corporation. All rights reserved. > The host is a 64-bit Windows 7 machine. Windows Server 2008 R2, 64-bit, SP1 > How have you been testing VS2012 builds? In what environment? The most notable difference is that I have no pre-VS2012 Microsoft compilers installed and no SDKs installed by my explicit action. I suggest assessing how the Framework64 directories get into your path and trying without them. nm
On 01/24/2013 09:38 AM, Noah Misch wrote: > The most notable difference is that I have no pre-VS2012 Microsoft compilers installed and no SDKs installed by my explicit action. I suggest assessing how the Framework64 directories get into your path and trying without them. nm Interesting. The Framework64 directory is added to the PATH by vcvarsall.bat from VS 2012. I suspect what's happening is that VS assumes that if there's a Framework64 directory, it contains 64-bit compilers and tools from VS 2012. In my case, I have 64-bit tools from Windows SDK 7.1, but VS Express 2012 doesn't include a 64-bit toolset (only a cross-compiler) so the corresponding ones from 2012 aren't there. Alternately, the Windows SDK 8 installer may have installed the .NET Framework 4.5 64-bit components, and VS 2012 might not be expecting them. All this stuff is a terrifying pile of underdocumented hacks and mess upon hacks and mess, so it wouldn't be particularly surprising. If I manually prepend c:\Windows\Microsoft.NET\Framework\v4.0.30319 to the PATH I get a successful build and vcregress check passes. I'll just have a quick read of the patch but so far it looks good to me. -- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
On 01/24/2013 09:38 AM, Noah Misch wrote: > The most notable difference is that I have no pre-VS2012 Microsoft > compilers installed and no SDKs installed by my explicit action. I > suggest assessing how the Framework64 directories get into your path > and trying without them. nm A further update on this: C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\vcvarsall.bat calls: C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\vcvars32.bat which in turn runs: @call "%VS110COMNTOOLS%VCVarsQueryRegistry.bat" 32bit No64bit to start: C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\Tools\VCVarsQueryRegistry.bat When I run this directly with the same arguments it adds to the environment: Framework35Version=v3.5 FrameworkDIR32=c:\Windows\Microsoft.NET\Framework64\ FrameworkVersion32=v4.0.30319 which is pretty clearly bogus. It looks like the script calls the subproc :GetFrameworkDir32Helper32 HKLM which does: reg query "HKLM\SOFTWARE\Microsoft\VisualStudio\SxS\VC7" /v "FrameworkDir32 resulting in: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\SxS\VC7 FrameworkDir32 REG_SZ c:\Windows\Microsoft.NET\Framework64\ .... which seems wrong. So it's clear that something's dodgy in how the various Microsoft tools have installed themselves, and it's nothing to do with your patch. Have you verified that 64-bit builds work? I'm testing now, but I've just confirmed that my machine isn't quite right. -- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
On 01/24/2013 11:28 AM, Craig Ringer wrote:
On 01/24/2013 09:38 AM, Noah Misch wrote:The most notable difference is that I have no pre-VS2012 Microsoft compilers installed and no SDKs installed by my explicit action. I suggest assessing how the Framework64 directories get into your path and trying without them. nm
OK, 64-bit builds with the x86_amd64 cross-compiler work. I cannot test native x64 builds as Microsoft no longer appear to release the native x64 compilers in any free SDK, but I see no reason there would be problems, nor any reason to hold back the work just in case. A 64-bit cross compile produces perfectly reasonable, working 64-bit binaries.Have you verified that 64-bit builds work? I'm testing now, but I've just confirmed that my machine isn't quite right.
I have some final revisions to propose for the documentation but otherwise this looks ready for commit.
I don't like the section on the Windows SDK at all. With all the variations it's grown cumbersome and it's unnecessary to install for most people. It may even cause problems - building an old Pg against a new WinSDK may introduce compatibility issues. I propose to omit that section entirely, and instead amend the section that discusses VS versions and compilers to mention that you can build with:
- VS 2008 to 2012 (no SDK required)
- Microsoft SDK 6.0a to 7.1 with included compilers
- VS 2005 + separately installed Microsoft SDK
I'd really like to link to the wiki for details of how to set up each environment, as the details change when Microsoft releases new SDKs and breaks old ones, new workarounds turn up, etc. I know we don't usually link to the wiki from the docs, but I feel in this case it's justified. I can just mention "look for Windows installation information on the PostgreSQL wiki" but would prefer a direct link.
Thankyou for documenting the locale issues. That will save somebody's sanity someday. I'd love to test the locale changes in detail, but available time doesn't permit that, and I don't see anything that will affect the behaviour of Pg when built with an older Visual Studio.
I've attached a patch with my amendments to the documentation. I think that with that, it's ready to go, but I'd like your final approval of the docs changes before I flag it ready for commit. The patch doesn't link directly to the wiki; if everyone's OK with that I'd like to get this in now and add any changes like that as a separate revision. It's also been pushed to https://github.com/ringerc/postgres/tree/vs2012
-- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
Attachment
On Thu, Jan 24, 2013 at 01:13:33PM +0800, Craig Ringer wrote: > I have some final revisions to propose for the documentation but > otherwise this looks ready for commit. These documentation changes are barely connected to the addition of VS 2012 support, so I think they should remain separate. > ! <para> > ! The full list of known-working development environments is: > ! </para> > ! > ! <itemizedlist> > ! <listitem><para>9.3 and above: Microsoft Visual Studio 2012, including Express (32-bit and 64-bit cross-compile)</para></listitem> > ! <listitem><para>9.2 and above: Microsoft Windows SDK 7.1 (32-bit and 64-bit)</para></listitem> > ! <listitem><para>9.2 and above: Visual Studio 2010, including Express (32-bit only)</para></listitem> > ! <listitem><para>9.0 and above: Visual Studio 2008, including Express (32-bit only)</para></listitem> > ! <listitem><para>8.2 and above: Visual Studio Express 2005 + Microsoft Windows Server 2003 R2 Platform SDK (32-bitonly)</para></listitem> > ! <listitem><para>8.2 and above: Visual Studio 2005 full version</para></listitem> > ! </itemizedlist> The official 9.0 and 9.1 64-bit builds are made with VS 2008, and the 9.2 builds with VS 2010.
On 01/25/2013 11:09 AM, Noah Misch wrote: > On Thu, Jan 24, 2013 at 01:13:33PM +0800, Craig Ringer wrote: >> I have some final revisions to propose for the documentation but >> otherwise this looks ready for commit. > These documentation changes are barely connected to the addition of VS 2012 > support, so I think they should remain separate. That's reasonable. > The official 9.0 and 9.1 64-bit builds are made with VS 2008, and the 9.2 > builds with VS 2010. Paid versions, though, right? That should be clearer, that 64-bit support exists but is absent (AFAIK) from Express editions. -- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
On Fri, Jan 25, 2013 at 11:20:56AM +0800, Craig Ringer wrote: > On 01/25/2013 11:09 AM, Noah Misch wrote: > > The official 9.0 and 9.1 64-bit builds are made with VS 2008, and the 9.2 > > builds with VS 2010. > Paid versions, though, right? So I hear. > That should be clearer, that 64-bit support exists but is absent (AFAIK) > from Express editions. Build farm member "chough" builds 64-bit using VS 2008 Express.
<div class="moz-cite-prefix">On 01/24/2013 01:13 PM, Craig Ringer wrote:<br /></div><blockquote
cite="mid:5100C2FD.70800@2ndQuadrant.com"type="cite"><div class="moz-cite-prefix">On 01/24/2013 11:28 AM, Craig Ringer
wrote:<br/></div><blockquote cite="mid:5100AA63.2050604@2ndQuadrant.com" type="cite"><pre wrap="">On 01/24/2013 09:38
AM,Noah Misch wrote:
</pre><blockquote type="cite"><pre wrap="">The most notable difference is that I have no pre-VS2012 Microsoft
compilers installed and no SDKs installed by my explicit action. I
suggest assessing how the Framework64 directories get into your path
and trying without them. nm
</pre></blockquote></blockquote><blockquote cite="mid:5100AA63.2050604@2ndQuadrant.com" type="cite"><pre wrap="">
Have you verified that 64-bit builds work? I'm testing now, but I've
just confirmed that my machine isn't quite right.
</pre></blockquote></blockquote> Just to confirm, I think that this is ready for commit as posted in <a
class="moz-txt-link-abbreviated"
href="mailto:20130101025421.GA17763@tornado.leadboat.com">20130101025421.GA17763@tornado.leadboat.com</a>.<br/><br />
I'llamend my docs changes and submit them separately. <br /><pre class="moz-signature" cols="72">-- Craig Ringer
<a class="moz-txt-link-freetext" href="http://www.2ndQuadrant.com/">http://www.2ndQuadrant.com/</a>PostgreSQL
Development,24x7 Support, Training & Services</pre>
On 01/25/2013 08:25 PM, Noah Misch wrote: >> That should be clearer, that 64-bit support exists but is absent (AFAIK) >> from Express editions. > Build farm member "chough" builds 64-bit using VS 2008 Express. Huh. My 2008 doesn't appear to have 64-bit compilers or cross-compilers and didn't offer them as an option. Need to look into that. -- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
On 01/26/2013 12:38 AM, Craig Ringer wrote: > On 01/25/2013 08:25 PM, Noah Misch wrote: >>> That should be clearer, that 64-bit support exists but is absent (AFAIK) >>> from Express editions. >> Build farm member "chough" builds 64-bit using VS 2008 Express. > Huh. My 2008 doesn't appear to have 64-bit compilers or cross-compilers > and didn't offer them as an option. > > Need to look into that. That might be a typo. The machine is currently offline waiting on a new CPU fan, but I'll check when it comes back up. cheers andrew
On Sat, Jan 26, 2013 at 12:20:56PM +0800, Craig Ringer wrote: > On 01/24/2013 01:13 PM, Craig Ringer wrote: > > On 01/24/2013 11:28 AM, Craig Ringer wrote: > >> On 01/24/2013 09:38 AM, Noah Misch wrote: > >>> The most notable difference is that I have no pre-VS2012 Microsoft > >>> compilers installed and no SDKs installed by my explicit action. I > >>> suggest assessing how the Framework64 directories get into your path > >>> and trying without them. > >> Have you verified that 64-bit builds work? I'm testing now, but I've > >> just confirmed that my machine isn't quite right. > Just to confirm, I think that this is ready for commit as posted in > 20130101025421.GA17763@tornado.leadboat.com. > > I'll amend my docs changes and submit them separately. Thanks. Here's a rebased version.
Attachment
On 01/26/2013 03:39 PM, Andrew Dunstan wrote: > > On 01/26/2013 12:38 AM, Craig Ringer wrote: >> On 01/25/2013 08:25 PM, Noah Misch wrote: >>>> That should be clearer, that 64-bit support exists but is absent >>>> (AFAIK) >>>> from Express editions. >>> Build farm member "chough" builds 64-bit using VS 2008 Express. >> Huh. My 2008 doesn't appear to have 64-bit compilers or cross-compilers >> and didn't offer them as an option. >> >> Need to look into that. > > That might be a typo. The machine is currently offline waiting on a > new CPU fan, but I'll check when it comes back up. On my VS Express 2008 (x64 Win7 SP1 host): Setting environment for using Microsoft Visual Studio 2008 x86 tools. C:\Program Files (x86)\Microsoft Visual Studio 9.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 9.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 9.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 9.0\VC> 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). -- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
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
> 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. Well, more compilers are always useful, but complaining that Microsoft might withdraw their working compilers smacks of 'what if?' paranoia. What if mingw support for Win64 was (sometimes/often/always/still) a bit rubbish? Oh wait ...
On 01/27/2013 02:48 PM, james wrote: >> 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. > > Well, more compilers are always useful, but complaining that Microsoft > might withdraw their working compilers smacks of 'what if?' paranoia. > What if mingw support for Win64 was (sometimes/often/always/still) a > bit rubbish? Oh wait ... > On the contrary, only a few months ago there was a far from groundless fear that Microsoft would do just that. Following considerable outcry they changed their mind. But this is definitely not just paranoia. As for w64 support, the mingw-64 project exists more or less explicitly to produce 64 bit compilers, including those hosted on mingw/msys. cheers andrew
> On the contrary, only a few months ago there was a far from groundless fear that Microsoft would do just that. Followingconsiderable outcry they changed their mind. But this is definitely not just paranoia. As for w64 support, the mingw-64project exists more or less explicitly to produce 64 bit compilers, including those hosted on mingw/msys. Huh. The only reason we have to use mingw64 or one of the assorted personal builds is because 'mingw support' doesn't deliver on its own, and last I looked there was a confusing variety of personal builds with various strengths and weaknesses. I managed to make some progress but we seem to be a ways off having a reference download (and ideally one with clang too I guess). I'd very much like there to be a good reference implementation, but the whole mingw/mingw64 thing is indicative of some problems, and reminds me of egcs. You have references to back up your statements, and demonstrate that it wasn't primarily FUD? FWIW I think the higher entry prices of pay-for VStudio almost guarantees continued availability of a free compiler, though it might end up slightly crippled, but I'm not a product planner for MS any more than you are.
On 01/27/2013 06:51 PM, james wrote: >> On the contrary, only a few months ago there was a far from >> groundless fear that Microsoft would do just that. Following >> considerable outcry they changed their mind. But this is definitely >> not just paranoia. As for w64 support, the mingw-64 project exists >> more or less explicitly to produce 64 bit compilers, including those >> hosted on mingw/msys. > > > Huh. The only reason we have to use mingw64 or one of the assorted > personal builds is because 'mingw support' doesn't deliver on its own, > and last I looked there was a confusing variety of personal builds > with various strengths and weaknesses. I managed to make some progress > but we seem to be a ways off having a reference download (and ideally > one with clang too I guess). > > I'd very much like there to be a good reference implementation, but > the whole mingw/mingw64 thing is indicative of some problems, and > reminds me of egcs. > > You have references to back up your statements, and demonstrate that > it wasn't primarily FUD? FWIW I think the higher entry prices of > pay-for VStudio almost guarantees continued availability of a free > compiler, though it might end up slightly crippled, but I'm not a > product planner for MS any more than you are. I blogged about it at the time: <http://people.planetpostgresql.org/andrew/index.php?/archives/276-Microsoft-throws-large-developer-communities-under-the-bus.html> and here when they relented a month later: <http://people.planetpostgresql.org/andrew/index.php?/archives/277-Microsoft-apparently-does-the-right-thing.html>. That was based on sources I considered credible at the time. But frankly, I'm not going to spend a lot of time digging up old references. If you think it's FUD then feel free, but I was and am far from alone in thinking it wasn't. Given the work I've put in over the years in supporting PostgreSQL on Windows I don't think any suggestion I have a bias against Microsoft has much credibility. As for mingw64, I still use this one: <http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Automated%20Builds/mingw-w64-bin_i686-mingw_20111220.zip/download>. The reason there isn't a later more official build is that they have screwed up their automated build process (which I also blogged about ;-) <http://adpgtech.blogspot.com/2013/01/mingw64-fail.html>). I'm going to try to get to the bottom of that when I get a chance. But this compiler works perfectly well AFAICT. It's been running on one of my buildfarm members quite happily for quite a while. cheers andrew
<div class="moz-cite-prefix">On 01/26/2013 10:56 PM, Noah Misch wrote:<br /></div><blockquote cite="mid:20130126145608.GA19977@tornado.leadboat.com"type="cite"><pre wrap="">On Sat, Jan 26, 2013 at 12:20:56PM +0800,Craig Ringer wrote:</pre><blockquote type="cite"><pre wrap="">Just to confirm, I think that this is ready for commitas posted in <a class="moz-txt-link-abbreviated" href="mailto:20130101025421.GA17763@tornado.leadboat.com">20130101025421.GA17763@tornado.leadboat.com</a>. I'll amend my docs changes and submit them separately. </pre></blockquote><pre wrap=""> Thanks. Here's a rebased version. </pre></blockquote> Is there any chance someone could pick this up for 9.3 before it diverges too much? It's ready to go,Windows only, and tested.<br /><br /><a href="https://commitfest.postgresql.org/action/patch_view?id=1023">https://commitfest.postgresql.org/action/patch_view?id=1023</a><br /><br/><br /><pre class="moz-signature" cols="72">-- Craig Ringer <a class="moz-txt-link-freetext" href="http://www.2ndQuadrant.com/">http://www.2ndQuadrant.com/</a>PostgreSQLDevelopment, 24x7 Support, Training & Services</pre>
On 02/01/2013 06:12 AM, Craig Ringer wrote: > On 01/26/2013 10:56 PM, Noah Misch wrote: >> On Sat, Jan 26, 2013 at 12:20:56PM +0800, Craig Ringer wrote: >>> Just to confirm, I think that this is ready for commit as posted in >>> 20130101025421.GA17763@tornado.leadboat.com. >>> >>> I'll amend my docs changes and submit them separately. >> Thanks. Here's a rebased version. > Is there any chance someone could pick this up for 9.3 before it > diverges too much? It's ready to go, Windows only, and tested. > > https://commitfest.postgresql.org/action/patch_view?id=1023 > > I expect to get to it in due course if nobody else does. I have been set back some by the death and replacement of my Windows workstation, (plus coming to terms with Windows 8). cheers andrew
On 02/01/2013 08:55 AM, Andrew Dunstan wrote: > > On 02/01/2013 06:12 AM, Craig Ringer wrote: >> On 01/26/2013 10:56 PM, Noah Misch wrote: >>> On Sat, Jan 26, 2013 at 12:20:56PM +0800, Craig Ringer wrote: >>>> Just to confirm, I think that this is ready for commit as posted in >>>> 20130101025421.GA17763@tornado.leadboat.com. >>>> >>>> I'll amend my docs changes and submit them separately. >>> Thanks. Here's a rebased version. >> Is there any chance someone could pick this up for 9.3 before it >> diverges too much? It's ready to go, Windows only, and tested. >> >> https://commitfest.postgresql.org/action/patch_view?id=1023 >> >> > > > > I expect to get to it in due course if nobody else does. I have been > set back some by the death and replacement of my Windows workstation, > (plus coming to terms with Windows 8). > > OK, I have looked at this and it seems perfectly sane. In fact, after a very frustrating time VS2012 is the *only* way I have found to get a 64 bit build using MS tools on Windows 8. Given that, I propose to backport these changes to 9.2 so we can get some buildfarm coverage of that tool chain that includes the latest stable release. cheers andrew
<p dir="ltr"><br /> On Feb 5, 2013 5:34 PM, "Andrew Dunstan" <<a href="mailto:andrew@dunslane.net">andrew@dunslane.net</a>>wrote:<br /> ><br /> ><br /> > On 02/01/2013 08:55AM, Andrew Dunstan wrote:<br /> >><br /> >><br /> >> On 02/01/2013 06:12 AM, Craig Ringer wrote:<br/> >>><br /> >>> On 01/26/2013 10:56 PM, Noah Misch wrote:<br /> >>>><br /> >>>>On Sat, Jan 26, 2013 at 12:20:56PM +0800, Craig Ringer wrote:<br /> >>>>><br /> >>>>>Just to confirm, I think that this is ready for commit as posted in<br /> >>>>> <a href="mailto:20130101025421.GA17763@tornado.leadboat.com">20130101025421.GA17763@tornado.leadboat.com</a>.<br/> >>>>><br/> >>>>> I'll amend my docs changes and submit them separately.<br /> >>>><br/> >>>> Thanks. Here's a rebased version.<br /> >>><br /> >>> Is thereany chance someone could pick this up for 9.3 before it diverges too much? It's ready to go, Windows only, and tested.<br/> >>><br /> >>> <a href="https://commitfest.postgresql.org/action/patch_view?id=1023">https://commitfest.postgresql.org/action/patch_view?id=1023</a><br />>>><br /> >>><br /> >><br /> >><br /> >><br /> >> I expect to get to it in duecourse if nobody else does. I have been set back some by the death and replacement of my Windows workstation, (plus comingto terms with Windows 8).<br /> >><br /> >><br /> ><br /> ><br /> > OK, I have looked at thisand it seems perfectly sane. In fact, after a very frustrating time VS2012 is the *only* way I have found to get a 64bit build using MS tools on Windows 8. Given that, I propose to backport these changes to 9.2 so we can get some buildfarmcoverage of that tool chain that includes the latest stable release.<br /><p dir="ltr">As long as it's fairly standaloneand doesn't change the actual cost around (mobile atm so i couldn't look at the actual patch), that seems likethe right idea to me. <p dir="ltr">/Magnus
On Tue, Feb 05, 2013 at 11:34:26AM -0500, Andrew Dunstan wrote: > OK, I have looked at this and it seems perfectly sane. In fact, after a > very frustrating time VS2012 is the *only* way I have found to get a 64 > bit build using MS tools on Windows 8. Given that, I propose to backport > these changes to 9.2 so we can get some buildfarm coverage of that tool > chain that includes the latest stable release. Thanks for reviewing. A backpatch seems adequately low-risk to me.