Re: Unable to compile postgres 13.1 on Slackware current x64
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: Thomas Munro <thomas.munro@gmail.com>, Condor <condor@stz-bg.com>,
"pgsql-generallists.postgresql.org"
<pgsql-general@lists.postgresql.org>
Date: 2020-11-16T18:11:03Z
Lists: pgsql-general
Laurenz Albe <laurenz.albe@cybertec.at> writes: > On Mon, 2020-11-16 at 12:30 -0500, Tom Lane wrote: >> In this case, I see one use of the constant TRUE in collationcmds.c, >> but I wonder how come that's there given that we deprecated upper-case >> TRUE some time ago. I find it hard to believe that sprinkling "#include >> <stdbool.h>" into random places is either necessary (on modern platforms >> anyway) or a good idea (if we're not using <stdbool.h>, this seems pretty >> much guaranteed to break things); so I think the rest of that patch is >> foolhardy. > How about this patch? It fixes the problem for me. What's wrong with s/TRUE/true/ in get_icu_language_tag? (I have zero interest in undoing 6337865f3, which is what this patch would amount to.) A larger issue is that it looks like ICU68 may insist on importing <stdbool.h> in some headers. That's fine on the platforms where we use <stdbool.h> anyway, but it's distinctly not fine elsewhere. We might be able to work around that the same way that dfmgr.h does: /* * On macOS, <dlfcn.h> insists on including <stdbool.h>. If we're not * using stdbool, undef bool to undo the damage. */ #ifndef PG_USE_STDBOOL #ifdef bool #undef bool #endif #endif This is going to be hard to test without a platform that doesn't use <stdbool.h> though. [ starts booting up spare PPC Mac ... ] regards, tom lane
Commits
-
Use "true" not "TRUE" in one ICU function call.
- ad84ecc98d7e 14.0 landed
- 89aa30a17968 11.11 landed
- 53c7b4f6221b 13.2 landed
- 029fa664ecb8 12.6 landed
-
Change TRUE/FALSE to true/false
- 2eb4a831e5fb 11.0 cited