statically linking with gij.o
Wed Apr 28 20:45:00 GMT 2004
It seems like it would be useful to link gij.o with a bunch of
application classes into an executable. One reason is to switch
dynamically different "main" classes, but even more valuable might be to
set properties and VM flags, and in general use the options that gij
With dynamic linking you just run gij and put the appropriate .so files
in the appropriate environment variables (LD_LIBRARY_PATH and CLASSPATH,
though I'm a little unsure of the specifics).
For static linking it's a little harder. We could do:
gcj -o foo gij.o foo.o bar.java baz.jar ...
However, gij.o does not get installed, and it's not clear how to do so
cleanly. A simple solution is to add it to libgcj.a - and maybe
libgcj.so? In that case it would become the "default" main if --main
isn't specified. I don't know if that's a good idea or not.
A possibly more elegant solution would be to create a new class, say
gnu.gcj.gij. It parses the flags and then calls the named class with
the remaining arguments, just like gij does. Presumably, they would
mostly use a common implementation, so you only have to add support for
a flag in one place. Then you could just do:
gcj -o foo --main=gnu.gcj.gij foo.o bar.java baz.jar ...
A problem with the "naive" implementation is that gnu.gcj.gij's main
method doesn't get called until after the VM is running and some of the
flags may effect VM startup. A solution is to add a special case to
jvgenmain for handling "gnu.gcj.gij".
Would either approach be reasonable/useful?
More information about the Java