Compilation by naive gcj usage results in ICE instead of a complaint. gcc-4.1.1, sources are the same in HEAD. $ gcc -o hello hello.java hello.java:1: internal compiler error: in uses_jv_markobj_p, at java/boehm.c:245 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://bugzilla.redhat.com/bugzilla> for instructions. Without ICE the result would be still confusing: /usr/lib/gcc/x86_64-redhat-linux/4.1.1/../../../../lib64/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' /tmp/cc4WVJmk.o: In function `hello::main(JArray<java::lang::String*>*)': hello.java:(.text+0x12): undefined reference to `_Jv_InitClass' hello.java:(.text+0x20): undefined reference to `java::lang::System::class$' hello.java:(.text+0x25): undefined reference to `_Jv_InitClass' hello.java:(.text+0x2c): undefined reference to `java::lang::System::out' /tmp/cc4WVJmk.o: In function `hello::hello()': hello.java:(.text+0x61): undefined reference to `java::lang::Object::Object()' /tmp/cc4WVJmk.o:(.data+0x80): undefined reference to `java::lang::Object::finalize()' /tmp/cc4WVJmk.o:(.data+0x88): undefined reference to `java::lang::Object::hashCode()' /tmp/cc4WVJmk.o:(.data+0x90): undefined reference to `java::lang::Object::equals(java::lang::Object*)' /tmp/cc4WVJmk.o:(.data+0x98): undefined reference to `java::lang::Object::toString()' /tmp/cc4WVJmk.o:(.data+0xa0): undefined reference to `java::lang::Object::clone()' /tmp/cc4WVJmk.o:(.data+0xa8): undefined reference to `java::lang::Object::throwNoSuchMethodError()' /tmp/cc4WVJmk.o:(.data+0x120): undefined reference to `vtable for java::lang::Class' /tmp/cc4WVJmk.o:(.data+0x148): undefined reference to `java::lang::Object::class$' /tmp/cc4WVJmk.o:(.eh_frame+0x12): undefined reference to `__gcj_personality_v0' collect2: ld returned 1 exit status Aware now the right way is to call: gcj -o hello --main=hello hello.java Attached patch errors out by: 'hello.java' must be compiled by the java gcj(1) driver but maybe some more spec-friendly solution would exist? Originally submitted as: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208454
Created attachment 12843 [details] Fix using a new gcc.c variable. 4.1.1 testsuite results not affected.
No, compiling .java should work with the gcc driver and if it does not, then there is a bug there. And we should not error out. Also the ICE is a bug which needs to fixed seperately from the "driver" issue anyways. The result without the ICE is not confusing at all: Without ICE the result would be still confusing at least to most C/C++/Fortran/Ada programmers :): /usr/lib/gcc/x86_64-redhat-linux/4.1.1/../../../../lib64/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' that means you did not include a main function. hello.java:(.text+0x12): undefined reference to `_Jv_InitClass' that means you did not include the library libgcj. These are all normal common problems for beginner programmers.
FWIW making the gcc driver work properly here is not easy. gcj reads a spec file with internal options in it. These are required for the proper operation of jc1.
(In reply to comment #3) > FWIW making the gcc driver work properly here is not easy. Why, every other language works the correct way.
The reason we did this is that, when we wrote libgcj, we wanted to be able to control various abi-changing things via command-line arguments. And, the best place to do much of the checking was in the libgcj configure script; many of the discoveries made here need to be known both to libgcj and to gcj at compile-time.
I thought I'd point out that you'll have to submit this patch the usual way; patches generally aren't reviewed in bugzilla. Also since this is a driver patch it probably won't get attention by the appropriate people, since it is filed as a java bug.
Closing as won't fix as the Java front-end has been removed from the trunk.