From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10546 invoked by alias); 19 Dec 2001 17:29:58 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 10351 invoked from network); 19 Dec 2001 17:28:40 -0000 Received: from unknown (HELO gash2.peakpeak.com) (207.174.178.17) by sources.redhat.com with SMTP; 19 Dec 2001 17:28:40 -0000 Received: from creche.cygnus.com (ta0206.peakpeak.com [204.144.244.206]) by gash2.peakpeak.com (8.9.3/8.9.3) with ESMTP id KAA15001; Wed, 19 Dec 2001 10:28:14 -0700 Received: (from tromey@localhost) by creche.cygnus.com (8.9.3/8.9.3) id KAA17738; Wed, 19 Dec 2001 10:36:05 -0700 To: Andrew Cagney Cc: law@redhat.com, gdb-patches@sources.redhat.com Subject: Re: Update for AC_PROG_STDC_CC fix References: <18104.1008708596@porcupine.cygnus.com> <3C206691.2010005@cygnus.com> X-Zippy: I'm not available for comment.. X-Attribution: Tom Reply-To: tromey@redhat.com From: Tom Tromey Date: Wed, 19 Dec 2001 09:29:00 -0000 In-Reply-To: Andrew Cagney's message of "Wed, 19 Dec 2001 10:06:09 +0000" Message-ID: <87pu5b6rjv.fsf@creche.redhat.com> X-Mailer: Gnus v5.7/Emacs 20.5 X-SW-Source: 2001-12/txt/msg00464.txt.bz2 >>>>> "Andrew" == Andrew Cagney writes: >> Or better yet, can we get rid of it completely from GDB? The only reason >> this causes problems is the bogus definition of prog_cc_stdc found when >> configuring gdb bleeds into other directories which use prog_cc_stdc >> via a shared config.cache. Andrew> Isn't something needed for HP/UX to get the compiler into the right Andrew> mode? But yes I agree, even after renaming the macro, there is a Andrew> problem with prog_cc_stdc clashes. I think clashes should only be a problem if you are using different versions of this macro in different directories. If so, that's a no-no. It has always been the case that all configure scripts in a given project must agree about how to compute cache values. I think this is an undocumented requirement :-(, but careful examination of the ChangeLogs will show bug fixes for problems like this dating back at least to 1996. HTH, Tom