From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24582 invoked by alias); 20 Dec 2006 00:23:01 -0000 Received: (qmail 24572 invoked by uid 22791); 20 Dec 2006 00:23:01 -0000 X-Spam-Check-By: sourceware.org Received: from mail-out4.apple.com (HELO mail-out4.apple.com) (17.254.13.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 20 Dec 2006 00:22:53 +0000 Received: from relay5.apple.com (a17-128-113-35.apple.com [17.128.113.35]) by mail-out4.apple.com (8.13.6/8.13.6) with ESMTP id kBK0MiET005071; Tue, 19 Dec 2006 16:22:44 -0800 (PST) Received: from [17.201.24.248] (unknown [17.201.24.248]) by relay5.apple.com (Apple SCV relay) with ESMTP id AFB41324002; Tue, 19 Dec 2006 16:22:37 -0800 (PST) In-Reply-To: <4588462E.1060701@lu.unisi.ch> References: <20061217031435.GA31219@nevyn.them.org> <45880EB3.7070101@lu.unisi.ch> <20061219191730.GA32355@nevyn.them.org> <4588462E.1060701@lu.unisi.ch> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <75167453-01CC-4C86-AFBC-D9395BD129CC@apple.com> Cc: "gcc-patches@gcc.gnu.org Patches" Content-Transfer-Encoding: 7bit From: Mike Stump Subject: Re: libgcc move to the top level Date: Wed, 20 Dec 2006 00:23:00 -0000 To: Daniel Jacobowitz X-Mailer: Apple Mail (2.749.3) X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2006-12/txt/msg01412.txt.bz2 On Dec 19, 2006, at 12:06 PM, Paolo Bonzini wrote: > If possible, I would like a proof of concept that it is possible to > migrate the building of the extra parts incrementally without > breaking non-converted targets, before committing (unless another > maintainer overrules me). One other random comment, I'd be nice to be able to do an rm -rf gcc and build just libgcc, quickly, with the installed gcc compiler... Same goes for all the runtime libraries. Initially, would be nice to pick a trivial target and flex the mechanism to be able to work in this fashion for that one target. Around here, we have to ship the shared libraries with the OS, so people can build and deploy gcc compiled software, and yet, we have more frequent tools releases that just ship gcc, without the shared libraries. We pick up extra `new' functionality with the .a library, while most of the symbols are resolved against the installed runtime library on the system. We don't install abi unstable libraries as shared libraries on the system to avoid abi breakages. I don't think the current work should be held up for this, just stating a direction to go for people to think about. Anyway, thanks for all your hard work.