Apache OpenOffice (AOO) Bugzilla – Issue 61278
java.lang.NullPointerException from HelpLinker while building helpcontent2/util/sbasic
Last modified: 2006-03-22 09:57:55 UTC
Current SRC680 builds (tried w/ m151, m152, m153) fail to compile due to a java.lang.NullPointerException from HelpLinker. I'm getting this with gcc 4.1 + gcj: HelpLinker @/tmp/mkQh8VG4 java.lang.NullPointerException at com.jclark.xsl.sax.XMLProcessorImpl.load (libxt.jar.so) at com.jclark.xsl.sax.XSLProcessorImpl.loadStylesheet (libxt.jar.so) at com.sun.star.help.HelpIndexer$ParseStuff.<init> (HelpLinker) at com.sun.star.help.HelpCompiler.getSourceDocument (HelpLinker) at com.sun.star.help.HelpCompiler.compile (HelpLinker) at com.sun.star.help.HelpLinker.link (HelpLinker) at com.sun.star.help.HelpLinker.main (HelpLinker) dmake: Error code 1, while making '../../unxlngi6.pro/bin/sbasic_en-US.zip' '---* tg_merge.mk *---' Guiseppe Ghibo is getting an almost identical error with gcc 4.0.3+SUN JDK 1.4.2_09: java -Xms256m -Xmx256m [...] com.sun.star.help.HelpLinker @/tmp/mkLAXKEB java.lang.NullPointerException at com.jclark.xsl.sax.XMLProcessorImpl.load (XMLProcessorImpl.java:630) at com.jclark.xsl.sax.XSLProcessorImpl.loadStylesheet (XSLProcessorImpl.java:101) at com.sun.star.help.HelpIndexer$ParseStuff.<init> (HelpIndexer.java:565) at com.sun.star.help.HelpCompiler.getSourceDocument (HelpCompiler.java:388) at com.sun.star.help.HelpCompiler.compile (HelpCompiler.java:191) at com.sun.star.help.HelpLinker.link (HelpLinker.java:434) at com.sun.star.help.HelpLinker.main (HelpLinker.java:228) dmake: Error code 1, while making '../../unxlngi6.pro/bin/sbasic_en-US.zip' '---* tg_merge.mk *---'
Works here without problems. ooo-build issue?
That original "HelpLinker" error could only happen in ooo-build :-) because HelpLinker is created from my experimental patch of issue 54692 which isn't upstreamed into normal OOo. There are some dependancies on that issue which might help you to find what the problem in ooo-build is. Perhaps ooo-build is including e.g. workspace.jaxpapi. Maybe see if the ooo-build patch matches the contents of the jaxpapi workspace
Caolan: thanks for explanation.
This is an issue of system xt diff from ooo-build. You may have a look at bug 59985 for updated version. Btw, soon in ooo-build.
Created attachment 33895 [details] workaround for xt module / gcj-4.1 (gcc bug 19870)
geki: For what it's worth IMO patching individual files to work around that bug is futile as all such constructs get miscompiled/mishandled by gcj, instead I suggest you look at the redhat spec for a *horrible* hack which aliases a script as gcj which seds out privates and protecteds before handing off to the true gcj
Where do I find that redhat spec thing?
Not related to the gcj bug after all -- A detailed description of what triggers this and how to fix it can be found at http://lists.ximian.com/pipermail/openoffice/2006-February/001647.html
Created attachment 34644 [details] Fix
The attached fix apparently breaks on Debian systems (see the various responses on the mailing list thread referred to above), but seems to work everywhere else. We should find a way to make this work everywhere before applying the fix, but I don't have a Debian box and the Debian maintainer doesn't seem to care about this fix because it works for him without the fix (Looks like Debian's default JAXP is Xerces).
I just want to add that it works on Gentoo without that fix just fine.
That is (as described in the mailing list posts and its followups) because many distributions (including Gentoo) use Xerces as their default JAXP implementation. The breakage occurs where something like classpath's JAXP is used as the default. The fix shouldn't break the systems that default to Xerces already either (it's just superfluous there -- telling gcj to use Xerces when it would already use Xerces by default).
bero: should arklinux do what everyone else does and setup xerces as their default japi handler :-)
Absolutely - we did already add a jaxp.properties file that fixes things without the patch on Ark too. But this should be fixed nevertheless, it's broken to use a generic API and rely on features present in (apparently) only one implementation -- especially given the same thing has been observed on other OSes and even other Java implementations. http://www.nabble.com/Re:-java.lang.NullPointerException-from-HelpLinker-p2614998.html
I hope we don't need to go to town and override all of java's/gij's default choices for the jaxp handlers, how about just adding a single -D of... -Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl ? looking at solenv/inc/tg_config.mk there's precedent in -Djavax.xml.parsers.SAXParserFactory=com.sun.xml.parser.SAXParserFactoryImpl (now also org.apache.xerces.jaxp.SAXParserFactoryImpl) used when invoking cfgimport.jar, clearly for a similar problem as this. I'll reassign this to me, caused by my proposed removal of com.sun.xml.foo to enable getting rid of problematic xml-apis.jar and jaxp.jar
accepting...
and -Djavax.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl I guess. Hopefully not the whole obscure lot :-)
There's no need to add the -D*jaxp*=*xerces* bits in other places -- I've verified all other parts of OOo compile (and actually work) ok even if classpath's jaxp stuff is used before setting our default to Xerces. I'm not sure if all the -Ds are needed, I only tried without any of them (getting the NullPointerException) and with all of them (works).
Commited -Djavax.xml.parsers.SAXParserFactory and -Djavax.xml.parsers.DocumentBuilderFactory to jaxpapi. Those are the only entry points used afaiks, so all should be ok now.
Verified
in m160