Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ceoZ6-0004z6-3a for pgsql-hackers@arkaria.postgresql.org; Fri, 17 Feb 2017 19:51:36 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1ceoZ5-0006wn-CP for pgsql-hackers@arkaria.postgresql.org; Fri, 17 Feb 2017 19:51:35 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ceoZ4-0006wX-GT for pgsql-hackers@postgresql.org; Fri, 17 Feb 2017 19:51:34 +0000 Received: from mail-qk0-x235.google.com ([2607:f8b0:400d:c09::235]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1ceoZ2-0005Ib-5c for pgsql-hackers@postgresql.org; Fri, 17 Feb 2017 19:51:33 +0000 Received: by mail-qk0-x235.google.com with SMTP id 11so53150703qkl.3 for ; Fri, 17 Feb 2017 11:51:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EVZk47KIOwy9wOoMifgrt2cH+QOplDOh9vnOH3KkcfY=; b=bswb13ClDS88R8LrgSLAaAHji6eP0M0znV7JOx9EuCoVXTwUhzA4lfaW4kBB/zQA0j kUPzUEJsYUkzxFxnize19LCv4x/fNYpmx1CMEVvxgkjWDUk8DYK5g62seuaX52aAOAB1 EUXol9KYehtUjILeC2V2pYd9FmIrq4/M/xqaDkpmRIhCvAg4uhbfuEaYtAoMrR2KSSbg 6pfYWhJlcyafBwD+s1lgrnurxY/xn2He6NaMBwwiAvCdL7pmmhwmXrW2KeVYfN4gFDTT 3DVk7t7UwWhM90YXkrHxwgR8w9LK+m7zPpveqkGYG9tNLMpcTEnI1jonkeyljrA5ASWT +mvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EVZk47KIOwy9wOoMifgrt2cH+QOplDOh9vnOH3KkcfY=; b=EPUAOAGuUYytpNq/Mi5P0RfFjMmrewAjvtINA5NFh/tZJTo+jaMrmTki77JCcUTP0a xha2VmtYTgxfpAajexgDOLjMnYv7mk5sGCXvtpS9V4EZ8rIZ0w3NQrKHAbma63dJC+EX Ylyk1My0bpAbcaORSLDEiyMICCsqqlaVaooKsuI1i/WLqFn8yOJhFvijFmG9GJ05TNk9 zt0PM4WhtIo+FlUNCq9Cu9/qAZx8MQkmvBMc74jb2h87KdOhcfqBZCYVTU2jFxNQ6lNh 0igKyMXksVrVtrbcok5FLN0YTKAaWibf/lVK/o3BwYgepfj80McrQX4rDYqLrY6trRT7 IrmQ== X-Gm-Message-State: AMke39ltDLRPi1xC3X4NfkNoMMfm7Z/Eyk/keOwOETGc1sgbca5/E263xq8TCqxHYxYHSA== X-Received: by 10.55.77.216 with SMTP id a207mr10211982qkb.63.1487361091210; Fri, 17 Feb 2017 11:51:31 -0800 (PST) Received: from [192.168.2.121] (24-113-198-113.wavecable.com. [24.113.198.113]) by smtp.gmail.com with ESMTPSA id q70sm6950170qkl.43.2017.02.17.11.51.29 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 17 Feb 2017 11:51:30 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: pg_recvlogical.c doesn't build with --disable-integer-datetimes From: Mark Dilger In-Reply-To: <2664.1487360457@sss.pgh.pa.us> Date: Fri, 17 Feb 2017 11:51:27 -0800 Cc: Alvaro Herrera , Thomas Munro , Pg Hackers , Andrew Dunstan Content-Transfer-Encoding: 7bit Message-Id: References: <20170217181348.a5pnflupslw2t6xx@alvherre.pgsql> <32279.1487355685@sss.pgh.pa.us> <2664.1487360457@sss.pgh.pa.us> To: Tom Lane X-Mailer: Apple Mail (2.3124) X-Pg-Spam-Score: -2.7 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org > On Feb 17, 2017, at 11:40 AM, Tom Lane wrote: > > I wrote: >> Yeah. I have longfin which is running Apple's clang, and is on a machine >> that doesn't have much to do otherwise. I propose to turn on -Werror in >> its configuration, and to configure a second critter on the same hardware >> that runs with -Werror as well as --disable-integer-datetimes. Somebody >> else should do similarly with a reasonably modern/stable gcc release. > > So I tried doing that by adding -Werror to longfin's CFLAGS environment, > and it crashed and burned in configure. The most obvious problem is > that we didn't bother to supply a prototype for does_int64_work() in > the probes for 64-bit ints. However, even after fixing that, configure > produces totally bollixed output because -Werror breaks many of its > built-in tests. We could fix the int64 tests but we have no good way of > fixing the built-in tests. > > AFAICS, if you want to build with -Werror, you have to configure without > that and then inject it afterwards. I wonder how people who use -Werror > are handling that. Is it possible to do at all in a buildfarm critter? I ran into the same problem when adding -Werror, and fixed it as follows: diff --git a/src/Makefile.global.in b/src/Makefile.global.in index d39d6ca..96fbc60 100644 --- a/src/Makefile.global.in +++ b/src/Makefile.global.in @@ -240,7 +240,7 @@ endif # not PGXS CC = @CC@ GCC = @GCC@ SUN_STUDIO_CC = @SUN_STUDIO_CC@ -CFLAGS = @CFLAGS@ +CFLAGS = @CFLAGS@ -Werror CFLAGS_VECTOR = @CFLAGS_VECTOR@ CFLAGS_SSE42 = @CFLAGS_SSE42@ That adds -Werror to the compilation of sources but not to the compilation of configure test programs. I'd be happy to hear if anybody has a cleaner way of doing this. Mark Dilger -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers