From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17758 invoked by alias); 26 Feb 2002 00:43:20 -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 17688 invoked from network); 26 Feb 2002 00:43:18 -0000 Received: from unknown (HELO potter.sfbay.redhat.com) (209.249.29.60) by sources.redhat.com with SMTP; 26 Feb 2002 00:43:18 -0000 Received: from dot.sfbay.redhat.com (dot.sfbay.redhat.com [205.180.230.224]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id g1Q0cCh24270; Mon, 25 Feb 2002 16:38:12 -0800 Received: (from rth@localhost) by dot.sfbay.redhat.com (8.11.6/8.11.6) id g1Q0hFk27845; Mon, 25 Feb 2002 16:43:15 -0800 X-Authentication-Warning: dot.sfbay.redhat.com: rth set sender to rth@redhat.com using -f Date: Mon, 25 Feb 2002 16:56:00 -0000 From: Richard Henderson To: Jeff Sturm Cc: Alexandre Oliva , Bryce McKinlay , Phil Edwards , Nic Ferrier , java@gcc.gnu.org, gcc@gcc.gnu.org Subject: Re: Get rid of libtool? [was Re: Makefile problems] Message-ID: <20020225164315.A27838@redhat.com> Mail-Followup-To: Richard Henderson , Jeff Sturm , Alexandre Oliva , Bryce McKinlay , Phil Edwards , Nic Ferrier , java@gcc.gnu.org, gcc@gcc.gnu.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from jsturm@one-point.com on Mon, Feb 25, 2002 at 12:45:11AM -0500 X-SW-Source: 2002-02/txt/msg01516.txt.bz2 On Mon, Feb 25, 2002 at 12:45:11AM -0500, Jeff Sturm wrote: > On 25 Feb 2002, Alexandre Oliva wrote: > > There are a lot of small details that, when > > added up, may turn into enough of a hassle that a lot of libtool's > > built-in intelligence ends up having to be duplicated, and poorly. > > Isn't that happening already for libgcc_s? No. The rules for building libgcc_s are quite simple, and are completely contained within one single makefile rule, which is brought in from some target-specific makefile fragment. The problems we're having with libgcc_s are philosophical wrt how it should be partitioned and used. There are zero problems with the actual construction of the library. r~