Re: 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

On Sat, Jun 2, 2012 at 11:26 PM, Brar Piening <brar(at)gmx(dot)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(at)hagander(dot)net> wrote:
> On Sat, Jun 2, 2012 at 11:26 PM, Brar Piening <brar(at)gmx(dot)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(at)pgadmin(dot)org> wrote:
> On Sun, Jun 3, 2012 at 11:22 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>> On Sat, Jun 2, 2012 at 11:26 PM, Brar Piening <brar(at)gmx(dot)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(at)hagander(dot)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-<http://blogs.msdn.com/b/visualstudio/archive/2012/06/08/visual-studio-express-2012-for-windows-desktop.aspx>
>

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(at)gmx(dot)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(at)gmx(dot)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

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 studio 2010

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 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?

> *** 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(at)41f00000000000000000000000000000 [c:\cygwin\home\nm\src\pg\postgresql\postgres.vcxproj]
postgres.exp : error LNK2001: unresolved external symbol _xmm(at)80000000000000008000000000000000 [c:\cygwin\home\nm\src\pg\postgresql\postgres.vcxproj]
postgres.exp : error LNK2001: unresolved external symbol _xmm(at)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

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 studio 2010
>
> 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

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(at)41f00000000000000000000000000000 [c:\cygwin\home\nm\src\pg\postgresql\postgres.vcxproj]
> postgres.exp : error LNK2001: unresolved external symbol _xmm(at)80000000000000008000000000000000 [c:\cygwin\home\nm\src\pg\postgresql\postgres.vcxproj]
> postgres.exp : error LNK2001: unresolved external symbol _xmm(at)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

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

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

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

On 01/21/2013 08:44 PM, Andrew Dunstan wrote:
>
> 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?

It's building on my Jenkins instance at the moment, to make sure it
doesn't break VS 2010 / Windows SDK 7.1 . I've merged it into HEAD and
pushed to https://github.com/ringerc/postgres/tree/vs2012; the only
conflict was a trivial one in the docs.

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

On 01/21/2013 09:06 PM, Craig Ringer wrote:

> It's building on my Jenkins instance at the moment, to make sure it
> doesn't break VS 2010 / Windows SDK 7.1 . I've merged it into HEAD and
> pushed to https://github.com/ringerc/postgres/tree/vs2012; the only
> conflict was a trivial one in the docs.

A quick update: No breakage of WinSDK 7.1 / VS 2010 was found.

I'm having to do more 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 2012
testing is still in progress. Expect a report in a few hours.

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

On 01/23/2013 02:14 PM, Craig Ringer wrote:
> On 01/21/2013 09:06 PM, Craig Ringer wrote:
>
>> It's building on my Jenkins instance at the moment, to make sure it
>> doesn't break VS 2010 / Windows SDK 7.1 . I've merged it into HEAD
>> and pushed to https://github.com/ringerc/postgres/tree/vs2012; the
>> only conflict was a trivial one in the docs.
>
> A quick update: No breakage of WinSDK 7.1 / VS 2010 was found.
>
> I'm having to do more 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 2012
> testing is still in progress. Expect a report in a few hours.
No go on VS 2012 yet.

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

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\ .

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

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.

"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... ]

The host is a 64-bit Windows 7 machine.

Error detail:

"c:\pg\postgresql\sdk8.0_cl17_vs11.0\x86\Release\vs2012\pgsql.sln"
(default target) (1) ->
"c:\pg\postgresql\sdk8.0_cl17_vs11.0\x86\Release\vs2012\postgres.vcxproj" (default
target) (2) ->
(PlatformPrepareForBuild target) ->
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]

"c:\pg\postgresql\sdk8.0_cl17_vs11.0\x86\Release\vs2012\pgsql.sln"
(default target) (1) ->
"c:\pg\postgresql\sdk8.0_cl17_vs11.0\x86\Release\vs2012\libpqwalreceiver.vcxproj"
(default target) (4) ->
"c:\pg\postgresql\sdk8.0_cl17_vs11.0\x86\Release\vs2012\libpq.vcxproj"
(default target) (5) ->
"c:\pg\postgresql\sdk8.0_cl17_vs11.0\x86\Release\vs2012\libpgport.vcxproj"
(default target) (6) ->
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\libpgport.vcxproj]

"c:\pg\postgresql\sdk8.0_cl17_vs11.0\x86\Release\vs2012\pgsql.sln"
(default target) (1) ->
"c:\pg\postgresql\sdk8.0_cl17_vs11.0\x86\Release\vs2012\pgevent.vcxproj"
(default target) (14) ->
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\pgevent.vcxproj]

Thoughts?

How have you been testing VS2012 builds? In what environment?

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

> On 01/23/2013 02:14 PM, Craig Ringer wrote:
>
> How have you been testing VS2012 builds? In what environment?

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 Windows Desktop RTM (Version
11.0.50727.42)

Regards,

Brar

On 01/24/2013 03:23 AM, Brar Piening wrote:
>> On 01/23/2013 02:14 PM, Craig Ringer wrote:
>>
>> How have you been testing VS2012 builds? In what environment?
>
> 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 Windows Desktop RTM (Version
> 11.0.50727.42)

... 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?

If you install the Windows 8 SDK, do you encounter issues?

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

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 the file 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
>
> Have you verified that 64-bit builds work? I'm testing now, but I've
> just confirmed that my machine isn't quite right.
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.

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

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-bit only)</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.

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. nm
>> 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(dot)GA17763(at)tornado(dot)leadboat(dot)com(dot)

I'll amend my docs changes and submit them separately.

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

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(dot)GA17763(at)tornado(dot)leadboat(dot)com(dot)
>
> I'll amend my docs changes and submit them separately.

Thanks. Here's a rebased version.

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. 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.

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

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(dot)GA17763(at)tornado(dot)leadboat(dot)com(dot)
>>
>> 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

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

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(dot)GA17763(at)tornado(dot)leadboat(dot)com(dot)
>>>
>>> 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(dot)GA17763(at)tornado(dot)leadboat(dot)com(dot)
>>>>
>>>> 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

On Feb 5, 2013 5:34 PM, "Andrew Dunstan" <andrew(at)dunslane(dot)net> wrote:
>
>
> 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(dot)GA17763(at)tornado(dot)leadboat(dot)com(dot)
>>>>>
>>>>> 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.

As long as it's fairly standalone and doesn't change the actual cost around
(mobile atm so i couldn't look at the actual patch), that seems like the
right idea to me.

/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.