From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3013 invoked by alias); 24 May 2011 18:59:28 -0000 Received: (qmail 2990 invoked by uid 22791); 24 May 2011 18:59:27 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from out3.smtp.messagingengine.com (HELO out3.smtp.messagingengine.com) (66.111.4.27) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 24 May 2011 18:59:13 +0000 Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.messagingengine.com (Postfix) with ESMTP id BD20A20E70 for ; Tue, 24 May 2011 14:59:12 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute4.internal (MEProxy); Tue, 24 May 2011 14:59:12 -0400 Received: from [158.147.67.90] (158-147-67-90.harris.com [158.147.67.90]) by mail.messagingengine.com (Postfix) with ESMTPSA id 80454405871; Tue, 24 May 2011 14:59:12 -0400 (EDT) Message-ID: <4DDBFFFF.8090909@cwilson.fastmail.fm> Date: Tue, 24 May 2011 18:59:00 -0000 From: Charles Wilson Reply-To: Charles Wilson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: cygwin@cygwin.com Subject: Re: Error building run2 from source package in win7 References: <20110523171750.GB16755@jethro.local.lan> <4DDA97CC.1090404@redhat.com> <4DDAA894.5090802@cwilson.fastmail.fm> <20110524183824.GA11571@jethro.local.lan> In-Reply-To: <20110524183824.GA11571@jethro.local.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com X-SW-Source: 2011-05/txt/msg00350.txt.bz2 On 5/24/2011 2:38 PM, David Sastre wrote: >> hmm...maybe the OP should check his generated config.h file for the >> offending def. If it's there, a quick look inside config.log should >> tell you why 'checking for an ANSI C-conforming const' is reporting 'no'. > > $ grep -nR "define const" run2-0.4.0-1/build/config.h > 152:#define const /**/ > > From the config.log: > > configure:12737: checking for an ANSI C-conforming const > configure:12802: gcc -c -Wall -Werror conftest.c >&5 > cc1: warnings being treated as errors > conftest.c: In function 'main': > conftest.c:69:10: error: 't' is used uninitialized in this function > conftest.c:85:23: error: 'b' may be used uninitialized in this function Looks like a possible bug in autoconf, which is where the definition of AC_C_CONST comes from -- or they might define this as PIBKAC (see below). The test really ought to be -Wall -Werror friendly, but that's up to the autoconf guys. Here's a simple test case: configure.ac AC_INIT([test]) AC_CONFIG_SRCDIR([configure.ac]) AC_C_CONST $ autoconf $ ./configure checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.exe checking for suffix of executables... .exe checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for an ANSI C-conforming const... yes $ ./configure CFLAGS="-Wall -Werror" checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.exe checking for suffix of executables... .exe checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for an ANSI C-conforming const... yes Hmm...that works fine. What about: $ ./configure CC="gcc -Wall -Werror" checking for gcc... gcc -Wall -Werror checking whether the C compiler works... yes checking for C compiler default output file name... a.exe checking for suffix of executables... .exe checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc -Wall -Werror accepts -g... yes checking for gcc -Wall -Werror option to accept ISO C89... none needed checking for an ANSI C-conforming const... no A-ha! Don't set -Werror as part of $CC, set it in $CFLAGS instead. -- Chuck -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple