From: | Craig Ringer <craig(at)2ndQuadrant(dot)com> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Noah Misch <noah(at)leadboat(dot)com>, Brar Piening <brar(at)gmx(dot)de>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Visual Studio 2012 RC |
Date: | 2013-01-21 13:06:35 |
Message-ID: | 50FD3D5B.9040506@2ndQuadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2013-01-21 13:10:33 | Re: Doc patch making firm recommendation for setting the value of commit_delay |
Previous Message | Tom Lane | 2013-01-21 13:06:09 | Re: gistchoose vs. bloat |