Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hTXLB-000370-K0 for pgsql-hackers@arkaria.postgresql.org; Wed, 22 May 2019 19:55:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hTXLA-00085i-97 for pgsql-hackers@arkaria.postgresql.org; Wed, 22 May 2019 19:55:56 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hTXLA-000854-0P; Wed, 22 May 2019 19:55:56 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hTXL7-0003cS-PE; Wed, 22 May 2019 19:55:55 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id x4MJtoLT011262; Wed, 22 May 2019 15:55:50 -0400 From: Tom Lane To: buildfarm-members@lists.postgresql.org cc: pgsql-hackers@lists.postgresql.org Subject: Re: FullTransactionId changes are causing portability issues In-reply-to: <6039.1558536488@sss.pgh.pa.us> References: <27054.1558533367@sss.pgh.pa.us> <6039.1558536488@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Wed, 22 May 2019 10:48:08 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11260.1558554950.1@sss.pgh.pa.us> Date: Wed, 22 May 2019 15:55:50 -0400 Message-ID: <11261.1558554950@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk I wrote: >> Our Solaris packager reports that 12beta1 is failing to build for him >> on some Solaris variants: >>> The link failure is: >>> Undefined first referenced >>> symbol in file >>> ReadNextFullTransactionId pg_checksums.o > On looking closer, the fix is simple and matches what we've done > elsewhere: transam.h needs to have "#ifndef FRONTEND" to protect > its static inline function from being compiled into frontend code. > So the disturbing thing here is that we no longer have any active > buildfarm members that can build HEAD but have the won't-elide- > unused-static-functions problem. Clearly we'd better close that > gap somehow ... anyone have an idea about how to test it better? Ah-hah --- some study of the gcc manual finds that modern versions of gcc have `-fkeep-inline-functions' In C, emit `static' functions that are declared `inline' into the object file, even if the function has been inlined into all of its callers. This switch does not affect functions using the `extern inline' extension in GNU C89. In C++, emit any and all inline functions into the object file. This seems to do exactly what we need to test for this problem. I've confirmed that with it turned on, a modern platform finds the ReadNextFullTransactionId problem with yesterday's sources, and that everything seems green as of HEAD. So, we'd obviously not want to turn this on for normal builds, but could we get a buildfarm animal or two to use this switch? regards, tom lane