Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1o7h8h-0008E0-HX for pgsql-hackers@arkaria.postgresql.org; Sat, 02 Jul 2022 17:42:39 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1o7h8g-0008DN-Ai for pgsql-hackers@arkaria.postgresql.org; Sat, 02 Jul 2022 17:42:38 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1o7h8g-0008DE-1s for pgsql-hackers@lists.postgresql.org; Sat, 02 Jul 2022 17:42:38 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1o7h8d-0000eV-0O for pgsql-hackers@lists.postgresql.org; Sat, 02 Jul 2022 17:42:36 +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 262HgXxr955007; Sat, 2 Jul 2022 13:42:33 -0400 From: Tom Lane To: Peter Eisentraut cc: pgsql-hackers@lists.postgresql.org Subject: Re: PSA: Autoconf has risen from the dead In-reply-to: <907591.1656778272@sss.pgh.pa.us> References: <1627398.1642955357@sss.pgh.pa.us> <652d5f5d-27e7-b1db-03e0-c74cfdca40cd@enterprisedb.com> <08af106d-10f0-4e1e-a1af-39dbb5920072@enterprisedb.com> <907591.1656778272@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Sat, 02 Jul 2022 12:11:12 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <955005.1656783753.1@sss.pgh.pa.us> Date: Sat, 02 Jul 2022 13:42:33 -0400 Message-ID: <955006.1656783753@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk I wrote: > So that explains part of it: most of the failures are down to using > Apple's hoary m4 instead of the one from MacPorts. We could usefully > warn about that in our own docs, perhaps. Hmm. I have just spent a very frustrating hour trying, and failing, to build any version of GNU m4 from source on either RHEL8 or current macOS. I don't quite understand why: neither the RPM specfile nor the MacPorts recipe for their respective m4 packages seem to contain any special hacks, so that it looks like the usual "configure; make; make check; make install" procedure ought to work fine. But it doesn't. I hit build failures (apparently because the source code is far too much in bed with nonstandard aspects of libc), or get an executable that SIGABRT's instantly, or if it doesn't do that it still fails some self-tests. With the latest 1.4.19 on macOS, the configure script hangs up, for crissakes. I am now feeling *very* hesitant about doing anything where we might be effectively asking people to build m4 for themselves. On the whole, I'm questioning the value of messing with our autoconf infrastructure at this stage. We did agree at PGCon that we'd keep it going for a couple years more, but it's not real clear to me why we can't limp along with 2.69 until we decide to drop it. regards, tom lane