From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10564 invoked by alias); 5 Dec 2002 19:31:43 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 10541 invoked from network); 5 Dec 2002 19:31:41 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 5 Dec 2002 19:31:41 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 55D5E3F30; Thu, 5 Dec 2002 14:31:13 -0500 (EST) Message-ID: <3DEFA97F.8070407@redhat.com> Date: Thu, 05 Dec 2002 11:31:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020824 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nathanael Nerode Cc: klee@apple.com, gdb-patches@sources.redhat.com, binutils@sources.redhat.com, newlib@sources.redhat.com, gcc@gcc.gnu.org Subject: Re: [RFC] Update to current automake/autoconf/libtool versions. References: <20021205190728.GA11507@doctormoo> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-12/txt/msg00300.txt.bz2 > I really would like to see the tree using autoconf 2.5x as soon as > possible; if this can be done before I autoconfiscate the top level > (which is not autoconfiscated yet) it will save me an awful lot of > trouble, since I can then use autoconf 2.5x for that autoconfiscation. > :-/ > > Your patch as is updates > bfd binutils gas gdb gprof ld mmalloc opcodes rda sim utils > > Can you please work up a patch for gcc 3.4 to update > boehm-gc fastjar gcc libf2c libffi libiberty libjava libobjc > libstdc++-v3 zlib Just a step back here. Some of the directories listed below belong to the FSF, but some don't. I don't think anyone can be asking Klee to update non FSF code. That's why I asked Klee to drop RDA from the original list. > And a patch for Insight > itcl libgui > > And one for Dejagnu > dejagnu expect > And for Newlib & Cygwin > libgloss newlib winsup > > And one for > sid > > and one for > intl > > -- > However, I think that it's OK to update one directory at a time, > provided we specify clearly what's going on, and get it all done before > the next release of anything. I don't think we can guarentee that, but I think we can live with the consequences :-/ > Accordingly, I suggest getting clean patches for small sets of > directories, making sure they work, getting them reviewed, and then > putting them in; and then starting on the next set. Keep sending update > notices to the various lists regarding which directories use the 'new' > tools and which use the 'old'. If you can make scripts which work > correctly under *both* autoconf 2.5x *and* autoconf 2.13, by all means > do so *first*, and mark those scripts as "compatibile with both", of > course; but I expect that will only happen for the simplest directories. > > If this is acceptable to other people in the various groups of course. > > I expect this will generate a certain amount of breakage, but then so > did my changes. In both cases, it needs to be done, we just have to > make sure all the breakage gets fixed. Andrew > --Nathanael > > P.S. > It was mentioned that autoconf2.5 scripts will have trouble with > building because of the top level passing down --target unconditionally. > > Unfortunately I think some other aspects of the configure scripts > require --target to be passed down unconditionally. :-/ Otherwise I'd > just change it. > > >