pg_locale compilation error with Visual Studio 2017
Hi,
I was building Postgres v10.3 sources on Windows x64-bit with Windows 10
SDK and v141 toolset (VS 2017) and it gives me the following error:
d:\pginstaller.auto\postgres.windows-x64\src\backend\utils\adt\*pg_locale.c(932):
error C2037: left of 'locale_name' specifies undefined struct/union
'__crt_locale_data'*
*[D:\pginstaller.auto\postgres.windows-x64\postgres.vcxproj]^M*
d:\pginstaller.auto\postgres.windows-x64\src\backend\utils\adt\*pg_locale.c(933):
error C2198: 'wchar2char': too few arguments for call
[D:\pginstaller.auto\postgres.windows-x64\postgres.vcxproj]^M*
I found the same error was raised by someone in pgsql-general lists but
don't see the submitted patch was committed. Here is the discussion link
/messages/by-id/CAL5LfdQdxt9u1W4oJmELybVBJE3X4rtNrNp62NNFw9n=Xd-wTQ@mail.gmail.com
The master branch also fails to compile with the same errors plus some
additional errors. Is it that Visual Studio 2017 is not completely
supported as of now and the latest version that should be used is VS 2015?
Or should I be using the older Windows SDK and toolset? I tried with
Windows 8.1 as well but it had some other issues.
Thanks.
--
Sandeep Thakkar
Sandeep Thakkar <sandeep.thakkar@enterprisedb.com> writes:
I found the same error was raised by someone in pgsql-general lists but
don't see the submitted patch was committed. Here is the discussion link
/messages/by-id/CAL5LfdQdxt9u1W4oJmELybVBJE3X4rtNrNp62NNFw9n=Xd-wTQ@mail.gmail.com
Yeah, that patch was rejected as unmaintainable, and it still is.
Somebody needs to do some research in Microsoft's docs and find out
what is the MS-approved way of getting the locale name now.
In the other thread, Munro wondered if ResolveLocaleName() would do
the trick, but AFAICS nobody has tried it.
Another idea would be to replace the whole mess with a lookup table,
although how to fill the table or maintain it in future would be
problematic too.
regards, tom lane
On Fri, May 11, 2018 at 10:39:07AM -0400, Tom Lane wrote:
In the other thread, Munro wondered if ResolveLocaleName() would do
the trick, but AFAICS nobody has tried it.
Indeed. I am pretty sure that it would be worth looking into that. The
VS docs shine by being obscure with this area, and each new version
arranges to make the locale lookups harder and harder.
Another idea would be to replace the whole mess with a lookup table,
although how to fill the table or maintain it in future would be
problematic too.
Let's never do that..
--
Michael
Michael Paquier <michael@paquier.xyz> writes:
On Fri, May 11, 2018 at 10:39:07AM -0400, Tom Lane wrote:
Another idea would be to replace the whole mess with a lookup table,
although how to fill the table or maintain it in future would be
problematic too.
Let's never do that..
Well, I dunno. There are a couple of advantages:
* It'd be independent of MSVC version, presumably, so we could
hope that it would stay fixed.
* It'd work for MinGW builds, which the current solution doesn't
(according to the comments in IsoLocaleName anyway).
Maintenance would be an issue, of course, but I doubt it'd be any
worse than for the Windows-timezone-name lookup table we have in
initdb/findtimezone.c. Which we've only touched twice in the last
seven years, AFAICT, and only one of those was per user complaint.
regards, tom lane