statically linked executable size

Mon Jul 3 07:16:00 GMT 2006

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Marco Trudel wrote:
> I noticed that a simple System.out.println() application will have 
> different executable sizes when compiling with different gcj versions 
> (althought it does exactly the same and needs exactly the same java 
> classes):
[...]
> What is the reason for it? There were already discussions in the list 
> about it, but I haven't found an explanation...
> Are there more/all classes compiled into the executables as libgcj grows?

One explanation is that more and more methods and classes get
implemented in newer GCJ releases, so you should expect to see
the executable size increase with newer GCJ releases.
What is particularly worrying to me is that the classes pulled
in seem to be increasing quite a bit with newer releases and
the visible bloat in statically-compiled executables keeps
increasing accordingly. For example, a single "Hello World"
executable for MinGW compiles to a 40MB statically-linked
executable (15MB when stripped of debugging information) and
contains a whopping 28,466 external symbols in the text section!
There are so many classes whose presence in the executable is
something that I cannot readily account for - for example, why
is javax.swing.JToolBar needed to print "Hello World" on the
console?
One response would be to make BC-ABI and a shared libgcj.dll
work for this platform, but I'm not sure that is anything more
than sweeping the problem under the carpet.
:-/

Thanks,
Ranjit.
- --
Ranjit Mathew Email: rmathew AT gmail DOT com
Bangalore, INDIA. Web: http://rmathew.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEqMQ9Yb1hx2wRS48RAukaAJ4rtrEKknFmT5sfl7O2zK3U8JZS8QCfXd2e
v4GphHTzh6PeDfhksQT+JHM=
=bitR
-----END PGP SIGNATURE-----