help with gcj for embedded platform

Scott Gilbertson
Fri Mar 26 16:03:00 GMT 2004

I'm not sure I'm the one to ask about what runtime environments are
available.  I'm developing a linux java application on x86, compiled with
GCJ.  My application uses AWT/xlib and is statically compiled and stripped.
I have found GCJ to be an excellent development tool for embedded systems
using x86 processors.  That's about the extent of what I know that's
relavent to your concerns.

Here are the main points about building applications for embedded systems
using Java, as I see things:

If you can get GCJ to produce binaries for your target hardware (which
sounds likely), I'd think it would be a good choice for your embedded
application, using static builds.  If you want a Java runtime (as opposed to
a native compiler), you're kind of stuck with big libraries, which is
probably no good for your application.  By the way, you can use GCJ as a
java runtime, and execute .class files with it, but it's large when used
that way, relative to a single statically-linked application.

I suspect your best bet is to bone up on command-line compilation and maybe
makefiles, and statically build a binary with GCJ.  Particularly so since
you're not using graphics, because apart from awt/swing (which are improving
rapidly) GCJ's library support is quite good.  Also, if there's some little
thing missing from the libraries and you post details and a test case on
this mailing list, it will often be fixed right away. Non-graphical,
statically-linked, stripped GCJ-compiled binaries are generally under two
megs, I think.

You compile each java file like so:
    gcj -O2 -c -o ClassFileName.o --classpath=.

In general, to do a static link, you link like so:
     gcj --main=SomeClassname -o
executableName -static -shared-libgcc -lstdc++ anObject.o anotherObject.o
I forget why I needed "-shared-libgcc".

To strip the executable (delete all the symbol information, etc., that's not
strictly required to run the program), do:
    strip executableName

Depending on what classes you're using, you may also need some "-u"
parameters on your link line, to force it to link in classes which are
dynamically loaded in your application (or in the libraries).  It's
generally easier, though to put lines like the following in one of your Java
files, which accomplishes the same thing:
    private static Class cl2 = gnu.gcj.convert.Output_UTF8.class;

I hope that helps.

Vladimir Levin wrote:
> Thanks very much for the help. I am quite new to this, having recently
> worked as a humble Java programmer in the J2EE world with relatively
> little knowledge of makefiles, etc. Is there some kind of standard
> runtime that includes everything one would likely need for an embedded
> platform? What kind of space would be required for this? We don't need
> any graphics (awt, swing), but otherwise we'd like to have a fairly
> useful and general set of classes, so that we don't have a constant
> headache with this stuff. I've looked at the CDC platform from Sun, and
> that would be great (looks as though it will run in about 2MB), but the
> licensing costs appear to be prohibitive.
> Vlad
> Scott Gilbertson wrote:
> >You typically only run one application in an embedded system, so the
> >library doesn't buy you anything.  If that's the case, do a static build
> >the size of your binary will be smaller than the dynamic binary plus the
> >library.  You can also strip the executable if you don't mind losing
> >meaningful stack dumps when an exception occurs.
> >
> >If you have more than one GCJ-compiled executable, you'd have to figure
> >which objects in the library aren't used in your application and remove
> >them.
> >
> >
> >
> >>Hello,
> >>
> >>I am trying to do a proof of concept that Java applications written with
> >>gcj can run on our embedded platform (Linux on Motoroal 855 with 16MB
> >>Ram total and about 3 MB allocated for Java environment + application).
> >>The default size of the gcj-3.3.3 is very large. Can someone
> >>help me with this matter or trimming the size of the shared library for
> >>use on an embedded platform?
> >>
> >>Vlad
> >>
> >>
> >>
> >>

More information about the Java mailing list