statically linking with gij.o

[Per Bothner <per at bothner dot com>]

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 
gives us.

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?
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/