Horton

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

Andres Freund <andres@anarazel.de>

View thread
From: Andres Freund <andres@anarazel.de>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Tristan Partin <tristan@neon.tech>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2023-11-18T00:03:23Z
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.

Hi,

On 2023-11-17 08:57:47 +1300, Thomas Munro wrote:
> I also had a go[3] at doing it with static inlined functions, to avoid
> creating a load of new exported functions and associated function call
> overheads.  It worked fine, except on Windows: I needed a global
> variable PGTYPESclocale that all the inlined functions can see when
> called from ecpglib or pgtypeslib code, but if I put that in the
> exports list then on that platform it seems to contain garbage; there
> is probably some other magic needed to export non-function symbols
> from the DLL or something like that, I didn't look into it.  See CI
> failure + crash dumps.

I suspect you'd need __declspec(dllimport) on the variable to make that work.
I.e. use PGDLLIMPORT and define BUILDING_DLL while building the libraries, so
they see __declspec (dllexport).  I luckily forgot the details, but functions
just call into some thunk that does necessary magic, but that option doesn't
exist for variables, so the compiler/linker have to do stuff, hence needing
__declspec(dllimport).

Greetings,

Andres Freund