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

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>

To: Peter Eisentraut <peter@eisentraut.org>

Cc: Thomas Munro <thomas.munro@gmail.com>, Tristan Partin <tristan@neon.tech>, pgsql-hackers <pgsql-hackers@postgresql.org>

Date: 2025-12-12T18:07:08Z

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 →

Revert "Tidy up locale thread safety in ECPG library."
- 3c8e463b0d88 18.0 landed
Tidy up locale thread safety in ECPG library.
- 8e993bff5326 18.0 landed
Revert "Blind attempt to fix _configthreadlocale() failures on MinGW."
- a62d90f2e5cb 18.0 landed
Require ucrt if using MinGW.
- 1758d4244616 18.0 landed
Remove configure check for _configthreadlocale().
- f1da075d9a03 18.0 landed
Simplify checking for xlocale.h
- 9c2a6c5a5f4b 18.0 landed
All supported systems have locale_t.
- 8d9a9f034e92 17.0 cited

Peter Eisentraut <peter@eisentraut.org> writes:
> On 28.08.24 20:50, Peter Eisentraut wrote:
>> I suggest that the simplification of the xlocale.h configure tests could 
>> be committed separately.  This would also be useful independent of this, 
>> and it's a sizeable chunk of this patch.

> To keep this moving along a bit, I have extracted this part and 
> committed it separately.  I had to make a few small tweaks, e.g., there 
> was no check for xlocale.h in configure.ac, and the old 
> xlocale.h-including stanza could be removed from chklocale.h.  Let's see 
> how this goes.

For the archives' sake --- I discovered today during a "git bisect"
session that commits between 35eeea623 ("Use thread-safe
nl_langinfo_l(), not nl_langinfo()") and 9c2a6c5a5 ("Simplify checking
for xlocale.h", the commit Peter refers to here) fail to build on
current macOS (26/Tahoe):

chklocale.c:330:8: error: call to undeclared function 'nl_langinfo_l'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
  330 |         sys = nl_langinfo_l(CODESET, loc);
      |               ^
chklocale.c:330:8: note: did you mean 'nl_langinfo'?
/Library/Developer/CommandLineTools/SDKs/MacOSX26.1.sdk/usr/include/_langinfo.h:116:20: note: 'nl_langinfo' declared here
  116 | char    *_LIBC_CSTR   nl_langinfo(nl_item);
      |                       ^
chklocale.c:330:6: error: incompatible integer to pointer conversion assigning to 'char *' from 'int' [-Wint-conversion]
  330 |         sys = nl_langinfo_l(CODESET, loc);
      |             ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
2 errors generated.

This happens because nl_langinfo_l() is declared in xlocale.h,
but chklocale.c elects not to #include that, evidently because
it's no longer needed to obtain typedef locale_t.

AFAICS there's nothing we can do about this retroactively;
it'll be a more or less permanent landmine for bisecting on macOS.
Fortunately it's not too difficult to work around, you can just do

diff --git a/src/port/chklocale.c b/src/port/chklocale.c
index 9506cd87ed8..0e35e0cf55f 100644
--- a/src/port/chklocale.c
+++ b/src/port/chklocale.c
@@ -23,9 +23,7 @@
 #include <langinfo.h>
 #endif
 
-#ifdef LOCALE_T_IN_XLOCALE
 #include <xlocale.h>
-#endif
 
 #include "mb/pg_wchar.h"
 
when trying to build one of the affected commits.  Another option
that might fit into a bisecting workflow more easily is to inject
-DLOCALE_T_IN_XLOCALE into CPPFLAGS.

			regards, tom lane