Here's a summary of other conversation:
> > > > Excessive code size growth could also be problem for some programs.
> > > >
> > > 1) A solution is using the -shared option to generate ".so" library.
> >
> > That does not solve things in environments like embedded
> > environments where there are no shared libraries.
>
> Use -Os and "strip --strip-all". And remove code if you don't like it.
>
> > > 2) Another future solution is pack the big ".so" library with UPX
> > > (Ultimate Packer for eXecutables) or extend the ELF format to
> > > permit pack the sections with GZ, BZ2 or LZMA.
> >
> > We are worried about code space in memory, not space on disk!
>
> Or extend the ELF format to permit pack non-solidly or solidly (=>
> slower stream) many subsections with GZ, BZ2, UPX or
> LZMA (<=1MiB to uncompress e.g.) variants to be refined all in one
> for better space ( only options -9, -best, ultra, ..).
>
> Their buffers are very small to permit to raise an exception.
> Like squashfs for embedded systems instead of cramfs.
This same idea is applicable to pack the gigantic /usr/lib/libgcj.so that
its current non-packed size on disk is >=9 MiB, sometimes >=50 MiB.
Remember, Java is generated to C++ with gcj and compiled with g++.
