Re: Binary size of statically linked java application

[Marco Trudel <mtrudel at gmx dot ch>]

Lehner, Michael wrote:
> > -----Original Message-----
> > From: Marco Trudel [mailto:mtrudel@gmx.ch]
> > Sent: Monday, November 27, 2006 8:22 PM
> > To: Andrew Haley
> > Cc: gnustuff@thisiscool.com; Lehner, Michael; java@gcc.gnu.org
> > Subject: Re: Binary size of statically linked java application
> >
> > I only provide statically compiled GCJs. So you have to look at the
> FAQ
> > in that context... Already the question "Why are the binaries so big?
> > With GCJ X.Y.Z, they were way smaller..." is completely useless in the
> > shared mode context...
> >
> >
> > Marco
>
> [Lehner, Michael] 
> Thank you for all the interesting information you provided to me. In the
> moment I am trying to build a toolchain with ulibgcj, but I am not sure
> if this will work, because they write on the project page, that it is
> for i686/amd64/.. but I am using a mips64 in the moment and this type is
> not listed.

In my understanding, micro-libgcj changes the source and doesn't do any 
platform dependent stuff. So I would guess that it will work for you.
The thing to remember is that a lot of useful stuff gets kicked out of 
the java class library and java language features. So check carefully if 
you don't need them before investing time for micro-libgcj.
I think you could always write an eMail to the maintainer of 
micro-libgcj if you have questions. He seemed to be quite a nice guy...


> I think I will have to manually reduce the size
> by removing unused packages.
> Is there a way to tell the linker to not use them,

Unfortunately no (or I don't know them). But it's possible to get a file 
which tells you what objects are included into your binary. Add: 
-Wl,-Map,Hello2.map
You can easily see that stuff like awt.o, swing.o, w3c.o and alike will 
always get into your binary.


> so that I won't need
> to rebuild my libgcj every time use a new package or I don't need one
> any longer? Or can I only exclude whole archives?

You don't need to rebuild GCJ. Thats why I meant that my approach is 
easier to maintain. What you have to do:
- extract all objects from the libgcj archive (ar x libgcj.a)
- remove the ones you don't need
- create the new archive (ar q libgcj.a *.o)
- compile your application again

Of course you will now get unresolved depencies because your objects are 
referenced from other classes in the class library. For those you have 
to write stubs (minimal classes) and add them to the compilation.
It needs quite some time, but it's worth the effort...


BTW: Did you think about shared compilation of GCJ?

Marco