Re: VS 2015 support in src/tools/msvc

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Petr Jelinek <petr(at)2ndquadrant(dot)com>
Cc: Christian Ullrich <chris(at)chrullrich(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: VS 2015 support in src/tools/msvc
Date: 2016-04-21 19:39:05
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 04/11/2016 03:47 AM, Michael Paquier wrote:
> On Mon, Apr 11, 2016 at 3:25 PM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)com> wrote:
>> Now, I have produced two patches:
>> - 0001-Support-for-VS-2015-locale-hack.patch, which makes use of
>> __crt_locale_data_public in ucrt/corecrt.h. This is definitely an ugly
>> hack, though I am coming to think that this may be the approach that
>> would us the less harm, and that's closer to what is done for VS 2012
>> and 2013.
>> - 0001-Support-for-VS-2015-getlocaleinfoex.patch, which make use of
>> GetLocaleInfoEx, this requires us to lower a bit the support grid for
>> Windows, basically that's throwing support for XP if compilation is
>> done with VS 2015.
>> Based on my tests, both are working with short and long local names,
>> testing via initdb --locale.
> The first patch is actually not what I wanted to send. Here are the
> correct ones...

I think I prefer the less hacky solution.

Progress report:

1. My VS 2015 installations (I now have several) all generate solution
file with:

Microsoft Visual Studio Solution File, Format Version 12.00

so I propose to set that as the solution file version.

2. The logic in win32.h is a bit convoluted. I'm going to simplify it.

3. I'm going to define _WINSOCK_DEPRECATED_NO_WARNINGS to silence some
compiler bleatings about the way we use the Winsock API

4. The compiler complains about one of Microsoft's own header files -
essentially it dislikes the=is construct:

typedef enum { ... };

It would be nice to make it shut up about it.

5. It also complains about us casting a pid_t to a HANDLE in
pg_basebackup.c. Not sure what to do about that.

5. most importantly, on my Release/X64 build, I am getting a regression
failure on contrib/seg. regression diffs attached. Until that's fixed
this isn't going anywhere.



Attachment Content-Type Size
seg-regression.diffs text/plain 8.0 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2016-04-21 19:47:08 Re: [COMMITTERS] pgsql: Add trigonometric functions that work in degrees.
Previous Message Alvaro Herrera 2016-04-21 19:31:13 Re: kqueue