From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0 Description of problem: The xerces-j2 SRPM fails to build with java-1.4.2-gcj-compat. It appears to be picking up org.w3c.dom classes from libgcj, instead of using the ones in xerces-j2. The libgcj ones define extra abstract methods which xerces classes don't implement. I'll attach the build log for review. I'm using gcc-java-4.0.0-0.35. Version-Release number of selected component (if applicable): xerces-j2-2.6.2-4jpp How reproducible: Always Steps to Reproduce: 1.Try to build the xerces-j2 SRPM 2. 3. Additional info:
Created attachment 112364 [details] Build log.
I looked at this a little. I suspect we want to back out xerces-j-build.patch and instead use the "IBM JDK 1.4" task to handle setting the compiler's bootclasspath properly. This note seems vaguely relevant: https://www.zarb.org/pipermail/jpackage-discuss/2004-June/005267.html I think we would also have to include the xerces tool jar in the SRPM. At least, the current sources don't include the ant task in question. Also, based on the above, we may need to hack the ant task a little, depending on whether and how it does the check of java.vendor.
The xalan-j2 SRPM is also failing to build because of the extra abstract methods. Hopefully this will disappear when the endorsed dirs stuff happens.
I don't think the java.endorsed.dirs patch will change anything here. That patch affects the runtime behavior of libgcj. In particular it lets you override selected parts of the core library. But as I read this bug, the problem is that the compiler is picking up newer XML classes than what it expects. That is, it is pulling these classes out of libgcj.jar directly (compilers don't as a rule use reflection for this sort of thing). So, endorsed dirs won't change anything there. That, plus some other stuff I read, suggests that the fix is to use the "IBM 1.4" build path.
I've made a hacked xjavac task which builds this correctly, and submitted a patch as http://issues.apache.org/bugzilla/show_bug.cgi?id=34551. Thanks for your help Tom.
This fix depended on both the xjavac hack and my adding gcj endorsed dirs support to xml-commons apis. The latter caused no end of problems (see bug 155693) and I've had to revert it, so I'm reopening this while I try and figure out other, less invasive ways to fix it.
Fixed in xerces-j2-2.6.2-4jpp_3fc
Created attachment 115279 [details] test case showing that xerces-j2 references but doesn't provide org.w3c.dom.TypeInfo xerces-j2-bz152255.patch breaks the xerces-j2 package under Sun's JDK. See the attached test case. The Apache-provided binary Ant (apache-ant-1.6.5-bin.tar.gz) references org.apache.xerces.dom3.TypeInfo and provides same: | $ jcf-dump \ | --classpath $ANT_HOME/lib/xercesImpl.jar \ | --print-constants \ | org.apache.xerces.dom.AttrImpl | grep -F .TypeInfo | - Implements: 106=org.apache.xerces.dom3.TypeInfo | Method name:"getSchemaTypeInfo" public Signature: 144=()org.apache.xerces.dom3.TypeInfo | | $ jar tvf $ANT_HOME/lib/xercesImpl.jar | grep TypeInfo | 411 Fri Feb 20 13:56:50 EST 2004 org/apache/xerces/dom3/TypeInfo.class In contrast, FC4's xerces-j2 references org.w3c.dom.TypeInfo but only provides org.apache.xerces.dom3.TypeInfo: | $ jcf-dump \ | --classpath /usr/share/java/xerces-j2-2.6.2.jar \ | --print-constants \ | org.apache.xerces.dom.AttrImpl | grep -F .TypeInfo | - Implements: 8=org.w3c.dom.TypeInfo | Method name:"getSchemaTypeInfo" public Signature: 140=()org.w3c.dom.TypeInfo | | $ jar tvf /usr/share/java/xerces-j2-2.6.2.jar | grep TypeInfo | 411 Thu May 05 09:16:28 EDT 2005 org/apache/xerces/dom3/TypeInfo.class Hence the exception in the attached test case.
Reopening. See comment #8.
Can you try it with xerces-j2-2.6.2-4jpp_8fc (from dist-fc5) and see if it fixed it?
I tested it and it fixes both the simple test case (attachment 115279 [details]) and my original use case that led me to this bug. I'm not sure what I should change the status to -- I'll leave that to you. Thanks.