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 1jvqxB-0000hS-Od for pgsql-hackers@arkaria.postgresql.org; Wed, 15 Jul 2020 23:36:45 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jvqxA-0002jP-MD for pgsql-hackers@arkaria.postgresql.org; Wed, 15 Jul 2020 23:36:44 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jvqxA-0002jI-FI for pgsql-hackers@lists.postgresql.org; Wed, 15 Jul 2020 23:36:44 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jvqx8-0002iS-BA for pgsql-hackers@lists.postgresql.org; Wed, 15 Jul 2020 23:36:44 +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 06FNackB3181176; Wed, 15 Jul 2020 19:36:38 -0400 From: Tom Lane To: Thomas Munro cc: PostgreSQL Hackers , rosset.filipe@gmail.com, Andrew Dunstan Subject: Re: sys_siglist[] is causing us trouble again In-reply-to: References: <3179114.1594853308@sss.pgh.pa.us> Comments: In-reply-to Thomas Munro message dated "Thu, 16 Jul 2020 11:21:53 +1200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3181174.1594856198.1@sss.pgh.pa.us> Date: Wed, 15 Jul 2020 19:36:38 -0400 Message-ID: <3181175.1594856198@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Thomas Munro writes: > On Thu, Jul 16, 2020 at 10:48 AM Tom Lane wrote: >> Oddly, we'd not get to this code unless configure set >> HAVE_DECL_SYS_SIGLIST, so it's defined *somewhere*. > It looks like glibc very recently decided[1] to hide the declaration, > but we're using a cached configure test result. Ah, of course. I was thinking that Peter had just changed configure in the last day or so, but that did not affect the back branches. So it's unsurprising for buildfarm animals to be using cached configure results. > I guess rawhide is the RH thing that tracks the bleeding edge? Yup. Possibly we should recommend that buildfarm owners running on non-stable platforms disable autoconf result caching --- I believe that's "use_accache => undef" in the configuration file. Alternatively, maybe it'd be bright for the buildfarm script to discard that cache after any failure (or at least configure or build failures). regards, tom lane