Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes: > On 1/23/19 6:01 PM, Tom Lane wrote: >> Perhaps there's some sort of setup that MinGW's version needs that >> we're not doing?
> This seems to suggest something worse: https://reviews.llvm.org/D40181 > Not sure I fully understand what's happening here, though. Me either, but I noted a couple of interesting extracts from that page: Normal mingw that uses msvcrt.dll doesn't have per-thread locales so it won't really work in any case (but I think it does define some sort of dummy functions that at least will allow it to build). Nowadays, mingw can be built to target ucrtbase.dll as well though, and there it should be possible to make it work just like for MSVC although it might need some patches. ... Looked into MinGW-w64 sources and this is indeed the case. _configthreadlocale will return -1 and will not do anything. This suggests that, rather than throwing up our hands if the initial _configthreadlocale call returns -1, we should act as though the function doesn't exist, and just soldier on the same as before. The code in there assumes that -1 is a can't-happen case and doesn't try to recover, but apparently that's over-optimistic. regards, tom lane
