From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 939 invoked by alias); 30 Dec 2003 09:12:44 -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 928 invoked from network); 30 Dec 2003 09:12:42 -0000 Received: from unknown (HELO gollum.inter.net.il) (192.114.186.22) by sources.redhat.com with SMTP; 30 Dec 2003 09:12:42 -0000 Received: from zaretski (pns03-195-8.inter.net.il [80.230.195.8]) by gollum.inter.net.il (Mirapoint Messaging Server MOS 3.3.8-GR) with ESMTP id CCY38567; Tue, 30 Dec 2003 11:12:36 +0200 (IST) Date: Tue, 30 Dec 2003 09:12:00 -0000 From: "Eli Zaretskii" To: mec.gnu@mindspring.com (Michael Elizabeth Chastain) Message-Id: <2927-Tue30Dec2003111014+0200-eliz@elta.co.il> CC: gdb-patches@sources.redhat.com In-reply-to: <20031230082625.140414B35A@berman.michael-chastain.com> (mec.gnu@mindspring.com) Subject: Re: [RFC] Fix compilation failure of remote-fileio.c Reply-to: Eli Zaretskii References: <20031230082625.140414B35A@berman.michael-chastain.com> X-SW-Source: 2003-12/txt/msg00519.txt.bz2 > Date: Tue, 30 Dec 2003 03:26:25 -0500 (EST) > From: mec.gnu@mindspring.com (Michael Elizabeth Chastain) > > ftp://sources.redhat.com/pub/binutils/autoconf-000227.tar.bz2 > > This version of autoconf identifies itself as "autoconf version 2.13", > but produces different "configure" files than autoconf 2.13. > Fun fun fun! Indeed! Thanks for the pointer, I will fetch that. > I would recommend: > > -- download autoconf 000227 > -- build your own private copy of it > -- check that it generates identical "configure" Okay, but how do you run autoconf to regenerate gdb/configure? I'm used to have some Makefile rule to DTRT, but I cannot seem to find it in the current CVS, or did I miss something? (The reason I'm asking something so stupid is because perhaps the errors I saw indicate that I invoked autoconf incorrectly.) > Do that before banging on configure.in Sure. For the moment, I've removed the change from configure.in, so as not to break the CVS version. This means that st_blocks in remote-fileio.c is not the optimal value on _all_ platforms (since HAVE_STRUCT_STAT_ST_BLOCKS is not defined anywhere), but at least GDB will compile and run in a reasonable way. > eli> Also, if it _is_ Autoconf 2.13, then it seems like it doesn't know > eli> about AC_CHECK_MEMBER, so what should I put in configure.in for > eli> testing the existence of st_blocks? > > Maybe cut-and-paste from the l_addr check? Thanks, I suspected that AC_TRY_COMPILE is the only way to go, but I wasn't sure, as my autoconf experience is virtually non-existent.