From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23539 invoked by alias); 5 Dec 2002 17:37:13 -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 23519 invoked from network); 5 Dec 2002 17:37:11 -0000 Received: from unknown (HELO dc-mx13.cluster1.charter.net) (209.225.8.23) by sources.redhat.com with SMTP; 5 Dec 2002 17:37:11 -0000 Received: from [66.189.46.2] (HELO platinum.local.) by dc-mx13.cluster1.charter.net (CommuniGate Pro SMTP 3.5.9) with ESMTP id 14522258; Thu, 05 Dec 2002 12:37:09 -0500 Date: Thu, 05 Dec 2002 09:37:00 -0000 Subject: Re: [RFC] Update to current automake/autoconf/libtool versions. Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) Cc: binutils@sources.redhat.com, gdb-patches@sources.redhat.com To: DJ Delorie From: Klee Dienes In-Reply-To: <200212051628.gB5GSKP19228@envy.delorie.com> Message-Id: <2D204CFD-0878-11D7-A7CE-00039396EEB8@apple.com> Content-Transfer-Encoding: 7bit X-SW-Source: 2002-12/txt/msg00155.txt.bz2 As far as I can tell offhand, none of the other patches depend on libiberty being updated, so one option is to upgrade the other directories, and leave libiberty alone. The downside of this is that gcc/binutils folks now need to keep multiple versions of the tools around, and I imagine it would play hell with --enable-maintainer-mode. In what way is it a bad time to change libiberty? I'm not arguing with the statement, just trying to understand the constraints a bit better. Would it be possible to convert the libiberty on the bib-branch, and import the binutils/gdb version from there? On Thursday, December 5, 2002, at 11:28 AM, DJ Delorie wrote: > >> There is a problem with libiberty and utils because GCC have their >> feet stuck in the ice > > Plus the libiberty master *is* gcc, so you can't apply the patches to > just the src side anyway. The libiberty in src is a "mere copy" of > the one in gcc. You must apply libiberty patches to gcc either at the > same time or before applying them to src (and now is a bad time to > change gcc's libiberty). > > Utils is not part of gcc. > >> (unless src, again splits off from GCC, but I suspect here we don't >> want to). > > Sorry, won't happen for libiberty. >