RE: Binary size of statically linked java application

["Lehner, Michael" <michaellehner at siemens dot com>]

> -----Original Message-----
> From: Marco Trudel [mailto:mtrudel@gmx.ch]
> Sent: Tuesday, November 28, 2006 10:16 AM
> To: Lehner, Michael
> Cc: gnustuff@thisiscool.com; java@gcc.gnu.org
> Subject: Re: Binary size of statically linked java application
> 
> Lehner, Michael wrote:
> >
> > [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...
> 
[Lehner, Michael] 
The problem is, that I really don't know what features someone would
perhaps need in the feature. I only make some research on how to include
java in the current development process. That means there are no classes
written for this project in java, but we perhaps want to use this
language later. In the current situation we are not using gcc for this
project, but there are other reasons why we also make some research if
gcc could solve all our needs. In the view of java this would be
perfect, because otherwise we would have to use 2 compilers for new
releases written in java and C.

> 
> > 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.

[Lehner, Michael] 
Because I didn't either find such properties for the linker I had the
fear that this is not possible. It would be a nice feature, because when
there are several developers provide their parts, everyone has other
dependencies and they could change every week. This means optimizing the
libgcj very frequently. 

> 
> 
> > 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...
> 
[Lehner, Michael] 
Perhaps I'll find a way to resolve these dependencies automatically or
use a list where all are listed and get a new libgcj every build. But
there is some time to solve this problem, first I will have to find out
how libgcj will work, when I want my applications to run without a Linux
system. Writing something simply out wont work, this is clear, but what
about calculations and other operations, not using any system specific
modules? We'll see.

> 
> BTW: Did you think about shared compilation of GCJ?
> 
[Lehner, Michael] 
Yes, but I did not spend very much thoughts an that, because I knew I
late won't be able to use this, because we are on our own system, which
is not really dynamic in loading modules from somewhere within the
filesystem. But this also means that I know all dependencies before
compilation and won't need later at runtime an additional one.

Michael