From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9940 invoked by alias); 16 May 2007 13:08:27 -0000 Received: (qmail 9799 invoked by uid 22791); 16 May 2007 13:08:25 -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; Wed, 16 May 2007 13:08:15 +0000 Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 1196121F685; Wed, 16 May 2007 09:09:22 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 16 May 2007 09:08:10 -0400 Received: from [127.0.0.1] (user-0c6suln.cable.mindspring.com [24.110.122.183]) by mail.messagingengine.com (Postfix) with ESMTP id C74A21670; Wed, 16 May 2007 09:08:09 -0400 (EDT) Message-ID: <464B0231.8000306@cwilson.fastmail.fm> Date: Wed, 16 May 2007 13:08:00 -0000 From: Charles Wilson User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: bonzini@gnu.org CC: newlib@sourceware.org, Alexandre Oliva , Steve Ellcey , GCC Patches , gdb-patches@sourceware.org, binutils@sourceware.org Subject: Re: Patch to update libtool in GCC and Src trees References: <200705111829.LAA24795@hpsje.cup.hp.com> <1178917335.26350.1189384841@webmail.messagingengine.com> <46454D61.7050509@cwilson.fastmail.fm> <46494FF1.2030304@cwilson.fastmail.fm> <464A615E.4070005@cwilson.fastmail.fm> <464ABAD4.3010409@lu.unisi.ch> In-Reply-To: <464ABAD4.3010409@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/msg00274.txt.bz2 Paolo Bonzini wrote: > >> (3) Should the configure.in's be changed to use the 'modern' libtool >> initialization macro LT_INIT([shared static win32-dll]) -- which will >> need to be committed simultaneously or as an integral part of Steve's >> update; or should they instead continue to use the old >> 'AC_LIBTOOL_WIN32_DLL; AM_PROG_LIBTOOL' macros? > > I prefer to do this one step at a time, because it applies to other > libraries too. OK. I'll regen the configure.in patch that way. Note1: the conversion from old-style libtool initialization macros to new-style can be done on a case-by-case basis after Steve's current update is committed; it needn't be an "all-at-once" megapatch. Note2: I mentioned that switching to the new macros would require making the newlib changes atomically with Steve's update of the toplevel libtool.m4&friends. This is a red herring; _LT_DECL_SED is /also/ only provided by the new .m4 files. So we need to make the newlib and toplevel changes atomically, regardless of whether the newlib configure.in's use old-style libtool initialization macros or new-style. >> (4) Once these questions are answered: Steve, do you want to 'absorb' >> this patch into your update, so it can be committed atomically? > > This would be best. Steve, please post your patch again in reply to > this message (I've added back binutils, gdb, and gcc mailing lists) and > I'll ok it. This ^^^ looks like Paolo's answer to question (1) from http://www.cygwin.com/ml/newlib/2007/msg00542.html is yes. I still need an answer to (2), probably from Jeff, and then I'll redo my whole 10-step procedure and retest tonight. Once that's done, I'll send Steve the *entire* set of changes (as produced mechanically by the scripts I posted earlier http://www.cygwin.com/ml/newlib/2007/msg00533.html) along with ChangeLog entries so he can 'absorb' it. -- Chuck