PATCH: Use libgcj convenience.la

Alexandre Oliva aoliva@redhat.com
Wed Jun 5 16:18:00 GMT 2002


On Jun  5, 2002, "David S. Miller" <davem@redhat.com> wrote:

> The memory usage of the libjava link, on the other hand is a _REAL_
> problem that ought to be fixed somehow.

One thing that could be done to alleviate this problem is to create
say per-package (in the Java sense) shared libraries, and get them all
linked together into a single shared library or so, but this would
trade build (time? and) memory requirements for run-time start-up
time, and would bring us back into the scary inter-shared-library
dependency land, from which we've recently moved away because of all
the undesirable properties thereof.

Another possibility is to create per-package libtool object files,
instead of libtool libraries (using -r to link a couple of libtool
object files together), that are then linked together into a single
library.  However, I'm not sure this final link would actually be less
demanding in terms of linking resources, and it might cause us to
exceed per-object GOT limits on platforms such as alpha and perhaps
mips.  So it's not clear there's a way out of this.

Let's face it: libjava *is* a huge library, and there's little we can
do about it.  If the linker doesn't manage resources efficiently, the
user loses.  If Solaris' linker can't do it properly, the user who
really wants libjava can always use the GNU linker instead, or get
more virtual memory.  Should we go out of our way to support Solaris'
linker?  (this assumes the numbers you've posted about linking libjava
on sparc-linux-gnu would be similar to those one would get when
linking libjava on sparc-solaris; I don't know of any reason why this
wouldn't be true)

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer



More information about the Gcc-patches mailing list