When running apache.tools.ant.Main with classfiles generated with gcj, the following error is thrown: java.lang.VerifyError: (class: org/apache/tools/ant/taskdefs/Tar, method: execute signature: ()V) Illegal use of nonvirtual function call at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:140) at org.apache.tools.ant.Project.init(Project.java:269) at org.apache.tools.ant.Main.runBuild(Main.java:582) at org.apache.tools.ant.Main.start(Main.java:196) at org.apache.tools.ant.Main.main(Main.java:235) This is the offending piece of code: try { Class taskClass = Class.forName(value); addTaskDefinition(key, taskClass); } catch (NoClassDefFoundError ncdfe) { The class files without passing optional flags to the gcj compiler (just the -C) Release: gcc-3.2 Environment: Configured with: ../configure --prefix=/usr --libdir=/usr/lib --with-slibdir=/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --enable-long-long --enable-__cxa_atexit --enable-languages=c,c++,ada,f77,objc,java --host=i586-mandrake-linux-gnu --with-system-zlib Thread model: posix gcc version 3.2 (Mandrake Linux 9.0 3.2-1mdk) How-To-Repeat: compile jakarta-ant 1.5 with gcj. and run it using Sun's vm.
Fix: Don't run with Sun's vm. :D
From: Tom Tromey <tromey@redhat.com> To: bhun@chello.nl Cc: gcc-gnats@gcc.gnu.org Subject: Re: java/8939: Class files produced by gcj are incompatible with Sun's vm Date: 31 Dec 2002 01:48:47 -0700 I looked at this PR a bit tonight. I believe the bytecode in question is this (I think this is the only invokespecial that could be considered incorrect): 395: invokespecial #223=<Method org.apache.tools.ant.taskdefs.Tar$TarCompressionMethod.compress (java.io.OutputStream)java.io.OutputStream> I believe this code in jcf-write.c is at fault: else if (DECL_CONSTRUCTOR_P (f) || CALL_USING_SUPER (exp) || METHOD_PRIVATE (f)) OP1 (OPCODE_invokespecial); I don't currently understand why this particular bytecode is considered invalid by the JDK. The method in question is in fact private. Most likely there is a special member class rule here that I'm unaware of; more research required. (Another possibility is that I'm on the wrong track here. It would help if you could send a correct Tar.class as compiled by javac...) Tom
From: Tom Tromey <tromey@redhat.com> To: bhun@chello.nl Cc: gcc-gnats@gcc.gnu.org Subject: Re: java/8939: Class files produced by gcj are incompatible with Sun's vm Date: 31 Dec 2002 09:12:47 -0700 >>>>> "Tom" == Tom Tromey <tromey@redhat.com> writes: Tom> 395: invokespecial #223=<Method org.apache.tools.ant.taskdefs.Tar$TarCompressionMethod.compress (java.io.OutputStream)java.io.OutputStream> Tom> The method in question is in fact private. Most likely there is Tom> a special member class rule here that I'm unaware of; more Tom> research required. I looked some more. It turns out that the reason is obvious: the method is private in another class. There is no special rule for a member class; we simply can't call this method. The JDK handles this case by adding an accessor method. That is what we need to do as well. Tom
"It's a bug." But it's kind of old. Is it fixed yet? Tom?
All gcj front end bugs have been fixed by the gcj-eclipse branch merge. I'm mass-closing the affected PRs. If you believe one of these was closed in error, please reopen it with a note explaining why. Thanks.