Just an idea... --- a/src/include/port/win32.h +++ b/src/include/port/win32.h @@ -16,7 +16,7 @@ * get support for GetLocaleInfoEx() with locales. For everything else * the minimum version is Windows XP (0x0501). */ -#if defined(_MSC_VER) && _MSC_VER >= 1900 +#if !defined(_MSC_VER) || _MSC_VER >= 1900 #define MIN_WINNT 0x0600 #else #define MIN_WINNT 0x0501
That was done to reveal the Vista locale stuff, which MingGW certainly has: we're calling it unconditionally in the master branch in at least one place (and we should do more of that, to make MSVC and MinGW code paths the same wherever possible). In 15 the users of GetLocaleInfoEx() are guarded with checks that you're on MSVC so it still wouldn't actually call them anyway. Obviously it's not good to change the target in the back branches. But apparently it already changed by accident due to some header order nonsense (could it be related to MinGW's recent switch to the UCRT by default?), so changing it again so that it compiles seems OK? We don't seem to have a documented MinGW support range, and I've always sort of assumed that it's just 'recent versions only' because it's effectively only for developers (cross builds and suchlike). And it certainly didn't really intend to be runnable on Windows XP (PostgreSQL 11 was the last to claim to run on Windows XP (0x0501)). I doubt anyone's actually going to test this on Vista or other ancient SDKs either, which is why I was looking for a change that *only* affects MinGW and doesn't risk changining anything for MSVC users on the retro-computers and toolchains we claim to support. For example, header order dependencies and side effects are a little chaotic on that OS, so you could easily break something else... I guess the objection would be that (apparently) some translation units are being compiled with 0x0603 from system headers, and this one would use 0x0600, which might be confusing.
