This is the mail archive of the
java-discuss@sources.redhat.com
mailing list for the Java project.
Re: Importing sources (?)
- To: tromey at cygnus dot com
- Subject: Re: Importing sources (?)
- From: Bryce McKinlay <bryce at albatross dot co dot nz>
- Date: Wed, 29 Nov 2000 13:35:18 +1300
- CC: jeff dot sturm at commerceone dot com, "green at cygnus dot com" <green at cygnus dot com>, "'Mo DeJong'" <mdejong at cygnus dot com>, "java-discuss at sourceware dot cygnus dot com" <java-discuss at sourceware dot cygnus dot com>
- References: <01C05801.64D583E0.green@redhat.com> <3A229A8F.5D1F76D@appnet.com> <87aealgj63.fsf@creche.cygnus.com>
Tom Tromey wrote:
> Jeff> How about embedded users? Does static linking still yield a
> Jeff> reasonable-sized executable?
>
> Static linking is probably broken in some ways right now. I think the
> default boot process wants to load some classes via Class.forName --
> classes which aren't referenced by any other means (and thus not
> linked in).
>
> So to static link you have to find these classes and pass `-U' options
> for the appropriate symbols to the linker. This is ugly and hard to
> use.
I think you're being a bit too pessimistic there Tom ;-)
Static linking was working fine last time I did it, a few weeks ago.
There are some (eg URL handler) classes which have issues due to
forName() usage, but there is nothing in the "boot process" to cause
problems that I am aware of. One easy solution to this would be to have
libgcj.zip on the classpath and let the interpreter find these classes.
Whether a static executable is reasonably sized is debatable. With a bit
of tweaking to the libgcj.spec file (or manual linking), its possible to
static link the libgcj stuff but still dynamically link glibc (this is
what I do to distribute our applications, in order to prevent problems
with incompatible changes to libgcj). From memory this yields an
executable in the 0.5mb-1.0mb range, stripped, for hello world. Probably
this could be reduced by disabling the interpreter etc.
The majority of the size of any Java binary is actually the debugging
symbols and EH frames rather than the code itself, so stripping has a big
effect. The introduction of the V3 ABI should improve this somewhat.
regards
[ bryce ]