This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: statically linking with gij.o
- From: Bryce McKinlay <mckinlay at redhat dot com>
- To: Per Bothner <per at bothner dot com>
- Cc: java at gcc dot gnu dot org
- Date: Wed, 28 Apr 2004 18:08:59 -0400
- Subject: Re: statically linking with gij.o
- References: <409017DF.6070409@bothner.com>
Per Bothner wrote:
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.
An alternative approach to property and runtime argument setting might
be to add support for a GCJ_ARGS environment variable. So perhaps you
could do something like:
GCJ_ARGS='--main=my.foo.Main' ./myapp
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.
I think eventually we'd like to make the compiler smart enough to find
the main() if one isn't specified. So it might be unwise to put in a
different meaning for this action.
Regards
Bryce