From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22110 invoked by alias); 8 May 2007 03:47:07 -0000 Received: (qmail 22093 invoked by uid 22791); 8 May 2007 03:47:06 -0000 X-Spam-Check-By: sourceware.org Received: from out1.smtp.messagingengine.com (HELO out1.smtp.messagingengine.com) (66.111.4.25) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 08 May 2007 03:47:02 +0000 Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 397DC21F68A; Mon, 7 May 2007 23:48:09 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Mon, 07 May 2007 23:47:01 -0400 Received: from [127.0.0.1] (user-0c6suln.cable.mindspring.com [24.110.122.183]) by mail.messagingengine.com (Postfix) with ESMTP id 7FAEF2A4D6; Mon, 7 May 2007 23:47:00 -0400 (EDT) Message-ID: <463FF2AE.3000503@cwilson.fastmail.fm> Date: Tue, 08 May 2007 03:47:00 -0000 From: Charles Wilson User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: bonzini@gnu.org CC: Steve Ellcey , binutils@sourceware.org, gcc-patches@gcc.gnu.org, gdb-patches@gcc.gnu.org, newlib@sourceware.org Subject: Re: Patch to update libtool in GCC and Src trees References: <463F6F90.4080401@cup.hp.com> <463F873D.5000706@lu.unisi.ch> In-Reply-To: <463F873D.5000706@lu.unisi.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-05/txt/msg00110.txt.bz2 Paolo Bonzini wrote: > >> Attached are the various changelogs for GCC and the src tree, the one >> diff for src-release, and then an attachment with the ToT libtool that >> I have been using for testing. > > What was the status of AIX testing? If that and Cygwin (possibly > including winsup/newlib -- CCing Charles Wilson) are ok, the patch can > go in as far as I'm concerned. Sorry if I'm being extra safe, but the > hardest to maintain parts are in now. ---- winsup/newlib, cygwin ----- Well, I just did a native build of a winsup/newlib tree (that is, module winsup checkout from src CVS repository) with Steve's ToT libtool changes applied at the toplevel. I had no significant issues (well, two problems, but they were unrelated and quickly fixed, and the cognizant persons notified). Which is unsurprising, because winsup itself doesn't use libtool; and newlib in /this/ configuration is also built sans libtool. However: on other platforms (see src/newlib/configure.host: at present, only linux native) newlib may in fact use libtool. It doesn't appear that any of Steve's patches address that: (1) src/newlib/configure.in says "AC_CONFIG_AUX_DIR(..)" so newlib will see the "new" ltmain.sh (2) src/newlib/Makefile.am says "ACLOCAL_AMFLAGS = -I ." so aclocal will use newlib/libtool.m4, which is "old", and NOT the "new" src/libtool.m4 and the other .m4 friends. Unless copies of the new libtool.m4&friends are placed in the newlib directory, or ACLOCAL_AMFLAGS is modified to search .. first, this is bound to cause problems (version skew in ../ltmain.sh vs. ./libtool.m4) for some people -- even if I didn't experience any problems on cygwin. It'd be nice to say "sure, go ahead and commit, and we'll take care of newlib-on-linux-native later". But I think if we do that, we will actually break newlib-on-linux-native, which is bad. So, there are two choices: (1) change newlib's AC_CONFIG_AUX_DIR to '.' and copy everything it might need from src/. into src/newlib/. -- which would include the old ltmain.sh, ltconfig, and lt-*.sh files, and regenerate all affected files. That is, postpone the newlib switchover to the new libtool. (2) remove newlib/libtool.m4, change newlib/Makefile.am's ACLOCAL_AMFLAGS to '-I .. -I .', regenerate all affected files. That is, switch newlib over to the new libtool now. Either way, Steve's existing patch needs to be extended to do _something_ with newlib, and that means a few more days of shakedown so the linux-native-newlib guys can test it. ---- gcc, NON-combined tree, cygwin ----- I last bootstrapped gcc on cygwin with Steve's ToT libtool changes about a week ago, and had no issues then. I don't see where anything in the last week would have changed that. ---- question about external tools ----- Ralf W. and I have been working on some refinements for cygwin/mingw libtool in libtool's ToT over the last few weeks. They are not yet ready, and I certainly do not want to hold back gcc progress waiting on libtool: the 20070318 libtool ToT included in Steve's update works fine as demonstrated above. However, now that Steve's done all or most of the _hard_ work, what will be the policy going forward with regards to updating external, but embedded, tools like libtool? How often will gcc re-import the latest libtool ToT? Any chance of another -- less disruptive! -- update before 4.THREE.0 ships? -- Chuck