This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libgcj/32619] -static-libgcj includes entire gnu classpath (>30MB executable from 95byte source)



------- Comment #3 from mtrudel at gmx dot ch  2007-07-04 06:59 -------
This is an old discussion and comes up in the mailinglist regularly. The most
promising approach is to explicitly exclude parts of the class library. JNC
(http://jnc.mtsystems.ch/) supports excluding the GUI stuff (AWT/Swing) and JCE
what already leads to a great size reduction (since these will be pulled into
every binary).

BTW, here the FAQ entry for your question from the JNC website:

Why are the binaries so big?
As JNC evolves, it supports more and more classes of the Java API. The problem
now is, that the Java API classes are heavily interconnected; a simple "Hello
World" application uses the security manager which uses AWT which uses...
Because of this, you will always have a big part of the classlibrary in your
binaries.
For Java, this is not a problem. Endusers require to have the JVM, thus having
all classes anyway. For native compilation, this is a bigger problem because
it's not just a bug that can be fixed. The design of Java doesn't fit into the
concept of native compilation (concerning the size of binaries).
Since JNC 0.9, you can exclude parts of the class library if you don't need
them and thus drastically reduce the size of your binaries.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32619


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]