This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: cross-module inlining (was Re: using gcj for a different language - is it possible?)
- From: Tom Tromey <tromey at redhat dot com>
- To: Jeff Sturm <jsturm at one-point dot com>
- Cc: Andrew Haley <aph at redhat dot com>, <java at gcc dot gnu dot org>
- Date: 09 Feb 2004 10:42:44 -0700
- Subject: Re: cross-module inlining (was Re: using gcj for a different language - is it possible?)
- References: <Pine.LNX.4.44.0402091056090.27817-100000@ops2.one-point.com>
- Reply-to: tromey at redhat dot com
>>>>> "Jeff" == Jeff Sturm <jsturm@one-point.com> writes:
Jeff> (That said, I realize many popular gcj projects like RHUG tend to build
Jeff> everything as a DSO, so Tom and I aren't necessarily in disagreement.)
Yeah, that's sort of the java style -- ship a .jar and some wrapper
to invoke it. Many java "programs" are reused in a different context
as a library: eclipse uses ant, ant uses javac, etc.
I'd like to make it so end users can have some choice over how they
build and deploy. E.g., if you want performance, you could compile
everything at once with the old-style "fast" ABI (presumably with a
static link at the end).
However, I think the default should be binary compatibility, aka
-findirect-dispatch. My reason is that this conforms most closely to
the language specification. For folks like Red Hat, shipping
precompiled applications, this default makes sense. E.g., if we want
to upgrade libgcj.so for some reason, we won't need to also rebuild
all the programs linked against it.
Tom