Patch: Fix for PR 2369

[Bryce McKinlay]

Jeff Sturm wrote:

>On Mon, 26 Nov 2001, Bryce McKinlay wrote:
>
>>I don't think this would effect .so compilation. The driver would pass 
>>the -fmain option to gcj in basically the same situations that it 
>>presently invokes jvgenmain and cc1 to do it (ie when linking an 
>>executable). If someone did "gcj Foo.o Bar.o" it would run jc1 
>>exclusivly to find main and generate the C main.
>>
>
>With the standalone jvgenmain, I can use tricks like:
>
>[jsturm@waterloo /tmp]$ gcj -shared -fPIC Hello.java -o libHello.so
>[jsturm@waterloo /tmp]$ gcj --main=Hello libHello.so -o main
>[jsturm@waterloo /tmp]$ ./main
>Hello World
>
>Note that jc1 doesn't run in the latter compilation.  This is very handy
>if libHello.so contains several entry points, so I can link small stub
>executables to launch it from different classes.
>
>Does this work with your proposed -fmain?  Is main() still generated in
>a separate object, or combined with the compiled java object?
>

main() would be combined with a compiled java object when building 
source files, but when linking like in this case, jc1 would be invoked 
just to generate main(), just how jvgenmain works now.

I'm not sure now whether its a good idea to try and validate that the 
specified --main exists when linking .o files, since it would depend on 
the given class being findable on the current sourcepath/classpath, and 
it may not neccessarily be there in all cases. When compiling from 
source it would definatly work though, as would "guessing" a main, and 
printing a better error when a --main is needed but not specified (and 
couldn't be guessed).

regards

Bryce.