From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33802) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sqp2L-00042D-Dr for qemu-devel@nongnu.org; Mon, 16 Jul 2012 13:24:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sqp2K-0004xA-Gz for qemu-devel@nongnu.org; Mon, 16 Jul 2012 13:24:45 -0400 Received: from cantor2.suse.de ([195.135.220.15]:45870 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sqp2K-0004x5-9u for qemu-devel@nongnu.org; Mon, 16 Jul 2012 13:24:44 -0400 Message-ID: <50044E56.8050408@suse.de> Date: Mon, 16 Jul 2012 19:24:38 +0200 From: Alexander Graf MIME-Version: 1.0 References: <1342360440-14328-1-git-send-email-sw@weilnetz.de> <500434C8.6050200@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] configure: Fix build with capabilities List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Blue Swirl , Stefan Weil , Eric Blake , qemu-devel@nongnu.org On 07/16/2012 05:40 PM, Peter Maydell wrote: > On 16 July 2012 16:35, Eric Blake wrote: >> On 07/15/2012 07:54 AM, Stefan Weil wrote: >>> Since commit 417c9d72d48275d19c60861896efd4962d21aca2 all configure tests >>> normally run with -Werror. Some of these tests now fail because they >>> raised a compiler warning. >> Nothing wrong with this patch, per se, but in the Autoconf world, the >> general advice is that programs should check whether -Werror is >> supported, but then avoid using it for the entire remainder of the >> configure script (that is, store the result of -Werror into a different >> variable that gets added into the final CFLAGS at make time, but not >> used during any of the rest of the configure time). That's because it's >> just too hard to avoid warnings-turned-into-errors for all possible >> versions (including future releases) of gcc, so you are just too likely >> to run into spurious changes in configurations when the next version of >> gcc starts warning about something new if you try to run all your >> configure tests with -Werror. > Hmm, good point -- unlike the actual program compile, failures > due to -Werror inside configure are silent and near-invisible. > Maybe we should back out 417c9d72 ? So how do we deal with the original problem then? The one where the build broke for me because the smartcard code got compiled in because configure didn't know that it would fail to compile with -Werror? Alex