Horton

Re: On non-Windows, hard depend on uselocale(3)

Thomas Munro <thomas.munro@gmail.com>

View thread
From: Thomas Munro <thomas.munro@gmail.com>
To: Peter Eisentraut <peter@eisentraut.org>, Andrew Dunstan <andrew@dunslane.net>
Cc: Tristan Partin <tristan@neon.tech>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2024-11-22T21:32:31Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Revert "Tidy up locale thread safety in ECPG library."

  2. Tidy up locale thread safety in ECPG library.

  3. Revert "Blind attempt to fix _configthreadlocale() failures on MinGW."

  4. Require ucrt if using MinGW.

  5. Remove configure check for _configthreadlocale().

  6. Simplify checking for xlocale.h

  7. All supported systems have locale_t.

Attachments

On Thu, Nov 21, 2024 at 8:38 PM Peter Eisentraut <peter@eisentraut.org> wrote:
> On 20.11.24 10:00, Thomas Munro wrote:
> > OK, do you think these three patches tell the _configthreadlocale()
> > story properly?  (Then after that we can get back to getting rid of
> > it...)
>
> Yes, this is very clear and helpful.  Thanks.

I realised that there is another aspect to this: it must be impossible
to build PostgreSQL with the original MinGW/MSYS project by now.  I
don't understand the history of the MinGW/MinGW-w64 fork, but if
they're both still live projects out there adding to the general
confusion about the frankenwindows multiverse, we should clarify our
situation.  As far as I know, we're only testing the second thing, and
only the second thing can use UCRT, and only the second thing is a
viable alternative toolchain for software that is primarily targeting
current Visual Studio, which I think is something we can say about our
project.  Right?

I was looking at the installation.sgml file and wondering where to
write "UCRT required" in the 0002 patch.  Perhaps we don't even need
to mention it if it's the default on MinGW-w64, but I think we do need
to remove the discussion of the original MinGW.  It's even pointing to
a cybersquatted URL.  I also suspect that MinGW-w64 shouldn't be
described as for "building 64 bit binaries" (maybe it started that way
but by now it's has other goals, modern libraries/APIs etc keeping up
with VC; and AFAICS it can build 32 bit binaries too, if anyone still
cares about that; wow, the naming of all this stuff is so confusing to
a non-Windows person, 32 and 64 get thrown around all over the place
with apparently no real meaning, but I digress...).  Andrew, would you
be interested in updating this section to talk only about the modern
installation and build steps for MinGW-w64/MSYS2 et al?  There are
several confusingly related projects and I'm not sure I'd get it right
if I tried, I've never used any of it...