Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1v48Mc-0099NO-RK for pgsql-bugs@arkaria.postgresql.org; Thu, 02 Oct 2025 01:44:10 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1v48MZ-005fc8-Pk for pgsql-bugs@arkaria.postgresql.org; Thu, 02 Oct 2025 01:44:08 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1v48MZ-005fc0-HN for pgsql-bugs@lists.postgresql.org; Thu, 02 Oct 2025 01:44:08 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1v48MX-001Azh-1k for pgsql-bugs@lists.postgresql.org; Thu, 02 Oct 2025 01:44:07 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 5921i1EI965387; Wed, 1 Oct 2025 21:44:01 -0400 From: Tom Lane To: Thomas Munro cc: Peter Dyballa , pgsql-bugs@lists.postgresql.org Subject: Re: BUG #19062: PostgreSQL 12.22 does not compile because of conflicting types for CollationCreate In-reply-to: References: <19062-878185d630b541b4@postgresql.org> <3315814.1758724884@sss.pgh.pa.us> <1F5AE8D5-EB64-4D93-83C1-15C821B96480@Web.DE> Comments: In-reply-to Thomas Munro message dated "Thu, 02 Oct 2025 13:08:30 +1300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <965385.1759369441.1@sss.pgh.pa.us> Date: Wed, 01 Oct 2025 21:44:01 -0400 Message-ID: <965386.1759369441@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Thomas Munro writes: > FTR what I was suggesting is something like CPPFLAGS="-D_STDBOOL_H" > (or append that to anything else you are already putting in CPPFLAGS > on the configure invocation), which should prevent from > having any effect, meaning it can't hide c.h's definition. I don't > know what concrete ABI dangers lurk in this area, but it doesn't look > like ICU uses bool in public interfaces, preferring its own UBool, a > typedef for int8_t. Hmm, so it's not immediately clear why it > includes it... but I'm too lazy to check. Yeah, it's hard to get excited about putting effort into this. As of PG 18 (97525bc5c) we've moved on permanently from supporting machines where the native bool type is not of size 1. Theoretically it should work in older branches as long as you don't try to interact with any libraries that use bool in their headers --- so taking out --with-libxml and perhaps --with-icu is probably the minimum requirement for that. But we haven't been testing such platforms since around 2022, so who knows if it still works in recent minor releases. Peter, perhaps an answer if you want to keep retrocomputing on this hardware is to use NetBSD? That does work for me on an old G4 laptop, and it has sizeof(bool) == 1. See buildfarm member mamba ... regards, tom lane