From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27937 invoked by alias); 25 Feb 2002 05:46:11 -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 27821 invoked from network); 25 Feb 2002 05:46:06 -0000 Received: from unknown (HELO cc730106-b.taylor1.mi.home.com) (68.40.33.180) by sources.redhat.com with SMTP; 25 Feb 2002 05:46:06 -0000 Received: from localhost (jsturm@localhost) by cc730106-b.taylor1.mi.home.com (8.9.3/8.9.3) with ESMTP id AAA26747; Mon, 25 Feb 2002 00:45:11 -0500 X-Authentication-Warning: mars.deadcafe.org: jsturm owned process doing -bs Date: Sun, 24 Feb 2002 22:05:00 -0000 From: Jeff Sturm X-Sender: jsturm@mars.deadcafe.org To: Alexandre Oliva cc: Bryce McKinlay , Phil Edwards , Nic Ferrier , java@gcc.gnu.org, gcc@gcc.gnu.org Subject: Re: Get rid of libtool? [was Re: Makefile problems] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-02/txt/msg01460.txt.bz2 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? > The only advantage I see for GCC in keep on using libtool is the > abstraction. But when we need a great deal of control over how the shared lib is built we have to get past the abstraction layer anyway. For any casual, naive attempts to build a shared lib I would wholeheartedly recommend libtool. For specific use like libgcj (and probably libstdc++) it is more debateable. Things I'd like to see (in no particular order): - symbol versioning (libgcj doesn't currently do this, but it could, and probably should). This is platform and tool specific, and to my knowledge libtool doesn't provide any assistance. - real incremental linking (*not* convenience libraries, which are a lousy substitute). - better performance (why couldn't some rules be baked into the makefile rather than evaluated for each compilation?). > Is it really worth to ditch > it in favor of a more limited solution that will require effort to put > in place and maintain? I'm not sure. For libgcj, we could always fall back to static-only on targets where we don't know how to build shared libs. I don't have much confidence that such targets would work even with libtool anyhow. For instance, libgcj assumes public data symbols are exported by default, which certainly isn't true on windows at least. That sort of detail isn't hidden by libtool's abstraction. Jeff