Visual Studio 2012 RC

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-<http://blogs.msdn.com/b/visualstudio/archive/2012/06/08/visual-studio-express-2012-for-windows-desktop.aspx&gt;

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

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/&quot;&gt;&lt;/&gt;.
</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@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

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/&quot;&gt;&lt;/&gt;.
</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@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.