From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26747 invoked by alias); 24 May 2007 21:14:40 -0000 Received: (qmail 26711 invoked by uid 22791); 24 May 2007 21:14:34 -0000 X-Spam-Check-By: sourceware.org Received: from out2.smtp.messagingengine.com (HELO out2.smtp.messagingengine.com) (66.111.4.26) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 24 May 2007 21:14:32 +0000 Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id E504F222FBB; Thu, 24 May 2007 17:14:30 -0400 (EDT) Received: from web6.messagingengine.com ([10.202.2.215]) by compute1.internal (MEProxy); Thu, 24 May 2007 17:14:30 -0400 Received: by web6.messagingengine.com (Postfix, from userid 99) id C72991B098; Thu, 24 May 2007 17:14:30 -0400 (EDT) Message-Id: <1180041270.4254.1191675307@webmail.messagingengine.com> From: libtool@cwilson.fastmail.fm To: "Steve Ellcey" , toa@pop.agri.ch Cc: jjohnstn@redhat.com, bonzini@gnu.org, newlib@sourceware.org, aoliva@redhat.com, gcc-patches@gcc.gnu.org, gdb-patches@sourceware.org, binutils@sourceware.org Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MessagingEngine.com Webmail Interface Subject: Re: New libtool is in the GCC and Src trees. In-Reply-To: <200705242032.NAA13355@hpsje.cup.hp.com> Date: Thu, 24 May 2007 21:14:00 -0000 References: <200705242032.NAA13355@hpsje.cup.hp.com> 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/msg00384.txt.bz2 On Thu, 24 May 2007 13:32:54 -0700 (PDT), "Steve Ellcey" said: > > gcc builds fail on Darwin. Attached a patch which cures the issue. > > Also, I'm analyzing the build failure in libjava, seems you forgot to > > regen the part in classpath. > > ltmain.sh is part of the new libtool, do you know if the ToT libtool has > this fixed? No, it does not. http://cvs.savannah.gnu.org/viewvc/libtool/libltdl/config/ltmain.m4sh?annotate=1.75&root=libtool see line 4968 However, wasn't the point of using ToT libtool: to _avoid_ haring off with quick-n-dirty [*] local patches -- in effect, forking libtool? Instead of fixing gcc's local copy, shouldn't this fix -- or a better one -- instead be submitted to libtool, and then gcc can resync? (At least in the medium-to-long term. For an immediate and temporary fix for a broken build, as long as it IS temporary...) [*] As Mike pointed out, the proposed change is not compatible with older compilers. -- Chuck