From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8213 invoked by alias); 7 May 2005 12:58:32 -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 7866 invoked from network); 7 May 2005 12:58:08 -0000 Received: from unknown (HELO one.firstfloor.org) (213.235.205.2) by sourceware.org with SMTP; 7 May 2005 12:58:08 -0000 Received: by one.firstfloor.org (Postfix, from userid 502) id 9BF28D033E; Sat, 7 May 2005 14:58:07 +0200 (CEST) To: tromey@redhat.com Cc: Richard Henderson , Alexandre Oliva , Andrew Haley , Per Bothner , Ranjit Mathew , GCC , GCJ , gcc@gcc.gnu.org Subject: Re: GCC 4.1: Buildable on GHz machines only? References: <20050427025707.GA20956@nevyn.them.org> <20050427053042.GA1317@redhat.com> <426F2611.7060801@3am-software.com> <426FD0DC.50601@codesourcery.com> <427962FC.5000305@bothner.com> <4279C184.6050909@gmail.com> <427A3F08.4000109@bothner.com> <17018.16701.719032.745892@cuddles.cambridge.redhat.com> <20050505201605.GB31978@redhat.com> <427A89FA.1060705@avtrex.com> From: Andi Kleen Date: Sat, 07 May 2005 23:29:00 -0000 In-Reply-To: (Tom Tromey's message of "06 May 2005 12:40:32 -0600") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2005-05/txt/msg00350.txt.bz2 Tom Tromey writes: > > Splitting up libgcj.so probably makes sense even for the Linux distro > case (the one I am most concerned with at the moment), just so that > apps that don't use AWT or Swing don't really pay for it. The Hmm? Unless you initialize AWT/swing in all programs that code should never be paged in for non GUI programs. Ok in theory if you use a random build order then a lot of pages could contain GUI and non GUI code together, but that is probably unlikely. The only reason to split it out would be to allow a libgcj installation that is not dependent on the X11 libraries on the RPM/dpkg/etc. level for small setups, but I am not sure how useful that is anymore for most distributions. And perhaps to make the linking steps in the gcc build a bit faster, but just for that it seems like a lot of work. > overhead of, say, BC-compiling AWT and putting it in a separate .so > doesn't seem unreasonable, based on our experiences with BC compiling > large apps. (Even this situation has its losers, for instance CNI > users accessing AWT, like the xlib peers. It looks impossible to > please everybody 100%.) > > This split would help Windows users, too, I think, as at least AWT and > Swing are fairly useless on that platform (no native peers; you can > run the Gtk peers but that is weird). > > For embedded platforms, I would not mind seeing patches to allow > completely disabling parts of the build based on configure switches. > E.g., a switch to drop AWT entirely would be fine by me. Someone Shouldnt the linker do that already at runtime? Ok you pay the cost of building it when gcc is built and storing the libraries on disk, but in the final executable all should be only linked in when actually referenced. I know it can take quite some effort to make libraries really static linking friendly so that libraries dont pull in other code intentionally (take a look at nm of a a static glibc program to see how it should be not done), but I would hope at least that the GUI and non GUI parts of libgcj are clearly separated. -Andi