Issue 61278 - java.lang.NullPointerException from HelpLinker while building helpcontent2/util/sbasic
Summary: java.lang.NullPointerException from HelpLinker while building helpcontent2/ut...
Alias: None
Product: utilities
Classification: Unclassified
Component: code (show other issues)
Version: OOo 2.0.1
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: caolanm
QA Contact: Unknown
Depends on:
Blocks: 54692
  Show dependency treegraph
Reported: 2006-01-28 22:40 UTC by bero
Modified: 2006-03-22 09:57 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

workaround for xt module / gcj-4.1 (gcc bug 19870) (811 bytes, text/plain)
2006-02-07 00:09 UTC, geki
no flags Details
Fix (1.04 KB, patch)
2006-03-07 17:47 UTC, bero
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description bero 2006-01-28 22:40:09 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 
   at com.jclark.xsl.sax.XMLProcessorImpl.load ( 
   at com.jclark.xsl.sax.XSLProcessorImpl.loadStylesheet ( 
   at$ParseStuff.<init> (HelpLinker) 
   at (HelpLinker) 
   at (HelpLinker) 
   at (HelpLinker) 
   at (HelpLinker) 
dmake:  Error code 1, while making '../../' 
'---* *---' 
Guiseppe Ghibo is getting an almost identical error with gcc 4.0.3+SUN JDK 
java -Xms256m -Xmx256m [...] @/tmp/mkLAXKEB 
   at com.jclark.xsl.sax.XMLProcessorImpl.load ( 
   at com.jclark.xsl.sax.XSLProcessorImpl.loadStylesheet 
   at$ParseStuff.<init> ( 
   at ( 
   at ( 
   at ( 
   at ( 
dmake:  Error code 1, while making '../../' 
'---* *---'
Comment 1 pavel 2006-01-29 08:39:12 UTC
Works here without problems.
ooo-build issue?
Comment 2 caolanm 2006-01-30 10:56:22 UTC
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
Comment 3 pavel 2006-01-30 10:58:36 UTC
Caolan: thanks for explanation.
Comment 4 geki 2006-02-06 23:41:12 UTC
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.
Comment 5 geki 2006-02-07 00:09:05 UTC
Created attachment 33895 [details]
workaround for xt module / gcj-4.1 (gcc bug 19870)
Comment 6 caolanm 2006-02-07 11:55:32 UTC
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
Comment 7 geki 2006-02-08 00:04:24 UTC
Where do I find that redhat spec thing?
Comment 8 bero 2006-03-07 17:46:02 UTC
Not related to the gcj bug after all -- A detailed description of what 
triggers this and how to fix it can be found at
Comment 9 bero 2006-03-07 17:47:39 UTC
Created attachment 34644 [details]
Comment 10 bero 2006-03-07 17:51:58 UTC
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).
Comment 11 geki 2006-03-07 18:00:23 UTC
I just want to add that it works on Gentoo without that fix just fine.
Comment 12 bero 2006-03-07 18:08:52 UTC
That is (as described in the mailing list posts and its followups) because 
many distributions (including Gentoo) use Xerces as their default JAXP 

The breakage occurs where something like classpath's JAXP is used as the 

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).
Comment 13 caolanm 2006-03-08 09:59:44 UTC
bero: should arklinux do what everyone else does and setup xerces as their
default japi handler :-)
Comment 14 bero 2006-03-08 13:41:58 UTC
Absolutely - we did already add a 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 
Comment 15 caolanm 2006-03-10 12:19:55 UTC
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...



looking at solenv/inc/ there's precedent in 
(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 to
enable getting rid of problematic xml-apis.jar and jaxp.jar
Comment 16 caolanm 2006-03-10 12:20:32 UTC
Comment 17 caolanm 2006-03-10 12:45:44 UTC
I guess. Hopefully not the whole obscure lot :-)
Comment 18 bero 2006-03-10 13:13:20 UTC
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).
Comment 19 caolanm 2006-03-10 14:21:52 UTC
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.
Comment 20 andreas.bille 2006-03-11 15:56:21 UTC
Comment 21 caolanm 2006-03-22 09:57:55 UTC
in m160