Description of problem: While trying to natively-compile the Eclipse automated tests, I ran into this weird issue with one of the jars. Version-Release number of selected component (if applicable): gcc-java-4.1.0-0.14.i386 java-1.4.2-gcj-compat-1.4.2.0-40jpp_55rh.i386 java-1.4.2-gcj-compat-devel-1.4.2.0-40jpp_55rh.i386 How reproducible: Always. Steps to Reproduce: 1. wget http://overholt.ca/converterJclMin.jar.1.jar 2. gcj -shared -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m32 -march=i386 -mtune=pentium4 -fasynchronous-unwind-tables -fPIC -findirect-dispatch -fjni -Wl,-Bsymbolic converterJclMin.jar.1.jar -o converterJclMin.jar.so Actual results: java/lang/Object.java:0: fatal error: the âjava.lang.Objectâ that was found in âjava/lang/Object.classâ didn't have the special zero-length âgnu.gcj.gcj-compiledâ attribute. This generally means that your classpath is incorrectly set. Use âinfo gcj "Input Options"â to see the info page describing how to set the classpath compilation terminated. Expected results: Successful compilation. Additional info: This is not the first jar in the aot-compile-rpm run. Many are compiled before this failure. I am using the system gcc from today's rawhide.
opsy. jar tvvf converterJclMin.jar.1.jar |grep Object 1368 Tue Jan 01 00:00:00 MST 1980 java/lang/Object.class gcj only likes to compile its own Object. I think we saw crashes when it compiled other variants of Object, and since we didn't want to support this, we decided to simply give an error if we detected this situation. I wonder where the classes in this jar come from. If they aren't from libgcj.jar then maybe we shouldn't be distributing them ...? Anyway, one fix would be not to compile this jar.
So -> NOTABUG ?
Yeah, NOTABUG.