Bug 39927 - Building FOP with GCJ
Building FOP with GCJ
Status: CLOSED WONTFIX
Product: Fop - Now in Jira
Classification: Unclassified
Component: general
trunk
PC Linux
: P2 normal
: ---
Assigned To: fop-dev
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2006-06-28 22:07 UTC by Matthew Burgess
Modified: 2012-04-30 00:17 UTC (History)
0 users



Attachments
Log of build failure (6.90 KB, text/plain)
2006-06-28 22:08 UTC, Matthew Burgess
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matthew Burgess 2006-06-28 22:07:55 UTC
Using Ubuntu 6.06 with gcj-4.1.0 installed, FOP trunk fails to build:

    [echo] Apache Ant version 1.6.5 compiled on October 26 2005
     [echo] VM: 4.1.0 (Ubuntu 4.1.0-1ubuntu8), Free Software Foundation, Inc.
     [echo] JAVA_HOME: /usr/lib/jvm/java-gcj/
     [echo] Jimi Support NOT Present
     [echo] JAI Support NOT Present
     [echo] JCE Support PRESENT
     [echo] JUnit Support NOT Present - Committers are required to have JUnit
working
     [echo] XMLUnit Support NOT Present - you can get it from
http://xmlunit.sourceforge.net

...

    [style] Processing /home/matthew/fop-trunk/src/codegen/encodings.xml to
/home/matthew/fop-trunk/build/gensrc/org/apache/fop/fonts/CodePointMapping.java
    [style] Loading stylesheet
/home/matthew/fop-trunk/src/codegen/code-point-mapping.xsl
    [style] Failed to process /home/matthew/fop-trunk/src/codegen/encodings.xml

BUILD FAILED
/home/matthew/fop-trunk/build.xml:315: java.lang.NullPointerException

I'm not sure whether this is a bug in FOP or a bug in GCJ or even in Xalan. 
Searching Ubuntu's bug database (https://launchpad.net/distros/ubuntu/+bugs),
there are no hits for either FOP (not surprising, as FOP isn't currently
packaged) or NullPointerException.

Let me know how I can help in debugging this one as I'm eager to get FOP
buildable under Ubuntu before 1.0!
Comment 1 Matthew Burgess 2006-06-28 22:08:54 UTC
Created attachment 18545 [details]
Log of build failure

Build log captured using `ant -verbose`
Comment 2 Jeremias Maerki 2006-06-29 08:46:22 UTC
The exception clearly happens in GNU Classpath's XSLT implementation
(gnu.xml.transform) which I've had rather bad experiences with. Frankly, I don't
understand why those guys reinvented the wheel instead of using Xerces and Xalan
but I guess it's because they think the Apache License is not compatible with
the GPL/LGPL. Either try to work with them to fix their bug or try to replace
their JAXP implementation with the latest Apache one (I don't know how to do
this with GCJ). I assume you'll run into additional problems with gnu.transform
when you've overcome this problem.

Besides that, I'm grateful for your willingness to help make FOP work with GCJ.
I'm looking into this, too, but only as a side-show. So your help is welcome.
Let's keep this issue open as a communication platform for this issue. I've
adjusted the subject slightly to adjust for that.
Comment 3 Matthew Burgess 2006-06-29 17:07:35 UTC
Thanks for the quick response, Jeremias.  There don't appear to be any relevant
bugs on either Ubuntu or GCC upstream using search terms like 'gcj' or
'transform'.  Plan of attack is:

1. Build GCC-SVN to see if the bug still exists
2. If it does, reduce the testcase then report it to GCC upstream and to Ubuntu,
linking to the upstream bug.
3. If the bug no longer exists in GCC-SVN, ascertain which patch fixed it and
backport it for inclusion in Ubuntu.

Regards,

Matt.
Comment 4 Matthew Burgess 2006-07-31 18:54:07 UTC
Sorry for taking so long on this.  I'm still able to reproduce the bug having
upgraded to gcc-4.1.1, so I've raised a bug at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28555 to see whether the
gcc/classpath folks can help us out.
Comment 5 Matthew Burgess 2006-08-02 09:50:32 UTC
Well, I've finally got passed those transform errors with the patch at
http://gcc.gnu.org/bugzilla/attachment.cgi?id=11991.  Now, my next problem is
that  tools.jar provided by java-gcj-compat wants the Eclipse Compiler for Java
(ecj) installed:

compile-java:
    [mkdir] Created dir: /sources/blfs/fop-0.92beta/build/classes
    [javac] Compiling 732 source files to /sources/blfs/fop-0.92beta/build/classes
    [javac] java-gcj-compat: tools.jar: failed to read
/usr/share/java/eclipse-ecj.jar

Quite why it needs ecj when gcj's already installed I don't know.  Oh well,
after trying to avoid having two Java compilers it looks like I'm going to need
them anyway!
Comment 6 Matthew Burgess 2006-08-02 10:44:54 UTC
And now I seem to have hit a pretty big problem!  I'm hoping it's just an
incorrectly configured environment:

    [javac] Compiling 732 source files to /sources/blfs/fop-0.92beta/build/classes
    [javac] ----------
    [javac] 1. ERROR in
/sources/blfs/fop-0.92beta/build/gensrc/org/apache/fop/fonts/CodePointMapping.java
    [javac]  (at line 1)
    [javac]
    [javac] package org.apache.fop.fonts;
    [javac]     ^
    [javac] The type java.lang.Object cannot be resolved. It is indirectly
referenced from required .class files
    [javac] ----------
    [javac] 1 problem (1 error)
Comment 7 Matthew Burgess 2006-08-02 11:55:19 UTC
In the meantime, it looks as if there's another bug in GCJ's 'transform'
package, or it's not being passed an option it requires. The generated
CodePointMappings.java contains lot's of XML entities such as '<', '>' and
'&'.  So, for whatever reason, they're not getting resolved to their
respective '<', '>' & '&' characters!
Comment 8 Jeremias Maerki 2006-08-02 11:55:50 UTC
I'm no specialist in that particular area, but both your last two comments make
me suspect that the real problem lies somewhere in Ant or rather its javac task.
AFAIK, GCJ can compile to .class files directly, i.e. it doesn't really need the
Eclipse Java Compiler. Maybe Ant does not deal correctly with your environment
selecting the right way to compile. Comment #6 goes in a similar direction. If
it doesn't find java.lang.Object it means the compiler has no class library at
its disposal. Ok, FOP's Ant build is not customized for use with GCJ, but I'd
expect the javac task to behave more or less the same whether you have a Sun JDK
or GCJ on your machine. Anyway, I'd check the Ant manual and FAQ for any clues
about problems like this.
Comment 9 Jeremias Maerki 2006-08-02 11:58:10 UTC
(In reply to comment #7)
> In the meantime, it looks as if there's another bug in GCJ's 'transform'
> package, or it's not being passed an option it requires. The generated
> CodePointMappings.java contains lot's of XML entities such as '&lt;', '&gt;' and
> '&amp;'.  So, for whatever reason, they're not getting resolved to their
> respective '<', '>' & '&' characters!

Ouch. That's a pretty basic thing. Maybe it would be worthwhile investigating if
you can inject Xerces/Xalan to replace the default JAXP set to avoid any nasty
problems with this.
Comment 10 Matthew Burgess 2006-08-02 12:07:21 UTC
(In reply to comment #9)
> (In reply to comment #7)
> > In the meantime, it looks as if there's another bug in GCJ's 'transform'
> > package, or it's not being passed an option it requires. The generated
> > CodePointMappings.java contains lot's of XML entities such as '&lt;', '&gt;' and
> > '&amp;'.  So, for whatever reason, they're not getting resolved to their
> > respective '<', '>' & '&' characters!
> 
> Ouch. That's a pretty basic thing.

Well, having had a quick look at code-point-mapping.xsl and the XSLT spec at
http://www.w3.org/TR/xslt#disable-output-escaping I think GNU's transform is
actually conformant as there is no explicit instruction, that I can see, to tell
it to not output conformant XML.
Comment 11 Jeremias Maerki 2006-08-02 12:15:27 UTC
(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #7)
> > > In the meantime, it looks as if there's another bug in GCJ's 'transform'
> > > package, or it's not being passed an option it requires. The generated
> > > CodePointMappings.java contains lot's of XML entities such as '&lt;',
'&gt;' and
> > > '&amp;'.  So, for whatever reason, they're not getting resolved to their
> > > respective '<', '>' & '&' characters!
> > 
> > Ouch. That's a pretty basic thing.
> 
> Well, having had a quick look at code-point-mapping.xsl and the XSLT spec at
> http://www.w3.org/TR/xslt#disable-output-escaping I think GNU's transform is
> actually conformant as there is no explicit instruction, that I can see, to tell
> it to not output conformant XML.

But disable-output-escaping is for the XML output method and we're using the
text output method. And it's not the output that's wrong, I think it's the
parsing of the stylesheet that's not happening as it should. The XSLT should
internally work with unescaped characters.
Comment 12 Jeremias Maerki 2006-08-02 13:04:56 UTC
I tried replacing the JAXP implementation and it actually helped. Getting
"access denied" message when writing into the /usr/share/ant1.6/lib directory
and being a Unix dummy, I downloaded Ant 1.6.5, extracted it to a new directory,
pointed ANT_HOME to it and symlinked ~/bin/ant to the right place. I then copied
all JAXP-related JARs from FOP's lib directory to Ant's lib directory. I then
set build.compiler=gcj in build-local.properties in FOP's home directory. When I
then run "ant" I get past code generation. However, compilation fails because
gcj does not find CodePointMapping.java although it has been generated (file is
there) and the gcj call looks good. Maybe that helps. No idea though, how to get
past this one. Maybe you have further ideas.
Comment 13 Matthew Burgess 2006-08-02 13:48:46 UTC
(In reply to comment #8)
> I'm no specialist in that particular area, but both your last two comments make
> me suspect that the real problem lies somewhere in Ant or rather its javac task.
> AFAIK, GCJ can compile to .class files directly, i.e. it doesn't really need the
> Eclipse Java Compiler.

Well, this seems to stem from the fact that ANT needs a tools.jar, and that
comes from java-gcj-compat.  It's that tools.jar that requires ecj (and no, I've
not figured out why yet).

> Comment #6 goes in a similar direction. If
> it doesn't find java.lang.Object it means the compiler has no class library at
> its disposal.

Yup, google suggest I need an rt.jar which I don't at the moment.  I'm trying to
figure out whether gcj or java-gcj-compat should be providing it.

(In reply to comment #11)
> (In reply to comment #10)
> > Well, having had a quick look at code-point-mapping.xsl and the XSLT spec at
> > http://www.w3.org/TR/xslt#disable-output-escaping I think GNU's transform is
> > actually conformant as there is no explicit instruction, that I can see, to tell
> > it to not output conformant XML.
> 
> But disable-output-escaping is for the XML output method and we're using the
> text output method. And it's not the output that's wrong, I think it's the
> parsing of the stylesheet that's not happening as it should. The XSLT should
> internally work with unescaped characters.

Yep, having had a longer look at the spec I see that the XSLT processor
shouldn't be doing any output escaping when using the text output method. So
yes, I'd agree, it looks like GNU's JAXP implementation is outputting what it
read in, rather than its internally resolved characters.

As both libxslt and Xalan output the resolved characters, I've reported this at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28572.


(In reply to comment #12)
> I tried replacing the JAXP implementation and it actually helped.

Good to know, but I'm still intent on having things work out of the box with
gcj.  Yes, I'm a glutton for punishment :-)

> I then set build.compiler=gcj in build-local.properties in FOP's home directory.

Doh!  I've just done this myself and my problem in comment 6 has now gone away.

> However, compilation fails because
> gcj does not find CodePointMapping.java although it has been generated (file is
> there) and the gcj call looks good. Maybe that helps. No idea though, how to get
> past this one. Maybe you have further ideas.

Unfortunately not.  Compilation of CodePointMapping.java is attempted here, but
obviously bails out when it sees those XML entities!

Thanks for your help Jeremias.  Do you mind if we keep this bug open so we can
keep track of how GCC are progressing and any other issues I run into further on
down the line?  That way everything's in one place in case anyone else is as
daft as me and tries to do this!
Comment 14 Matthew Burgess 2006-08-02 13:57:26 UTC
After manually using `sed' to resolve those XML entities I get to this:

   [javac]
/sources/blfs/fop-0.92beta/src/java/org/apache/fop/util/DOMBuilderContentHandlerFactory.java:68:
error: Type ‘ObjectBuiltListener’ not found in declaration of field ‘obListener’.

Adding "import org.apache.fop.util.ContentHandlerFactory.ObjectBuiltListener;"
works, but I suspect it's not the right fix?

Now I've hit a really nice one.  GCC's just segfaulted on me while trying to
compile layoutmgr/PageBreakingAlgorithm.java :-(
Comment 15 Jeremias Maerki 2006-08-02 14:12:17 UTC
(In reply to comment #13)
<snip/>
> Thanks for your help Jeremias.  Do you mind if we keep this bug open so we can
> keep track of how GCC are progressing and any other issues I run into further on
> down the line?  That way everything's in one place in case anyone else is as
> daft as me and tries to do this!

Yes, that's ok. Once it works we can write a Wiki or web page to provide
instructions for people who want to do the same.

(In reply to comment #14)
> After manually using `sed' to resolve those XML entities I get to this:
> 
>    [javac]
>
/sources/blfs/fop-0.92beta/src/java/org/apache/fop/util/DOMBuilderContentHandlerFactory.java:68:
> error: Type ‘ObjectBuiltListener’ not found in declaration of field ‘obListener’.
> 
> Adding "import org.apache.fop.util.ContentHandlerFactory.ObjectBuiltListener;"
> works, but I suspect it's not the right fix?

Well, Sun's compiler can do without so GCJ should probably be able to do the
same. Another bug report for you to file. :-(

> Now I've hit a really nice one.  GCC's just segfaulted on me while trying to
> compile layoutmgr/PageBreakingAlgorithm.java :-(

Eeeek. Looks like you'll need nerves of steel to finish this. I'd have given up
already for the lack of sufficient motivation. I'd probably resort to compiling
FOP separately and just concentrate on running it. But I guess if you're
tracking down all the little problems GCJ will obviously profit.

Comment 16 Matthew Burgess 2006-08-06 20:46:36 UTC
FYI, the patch mentioned in comment 5 has just been applied to the GNU Classpath
repository.  There are plans to backport most of the core library to the gcc-4.1
branch, though no timescales are known at present.
Comment 17 Glenn Adams 2012-04-04 21:48:40 UTC
gcj is not used by standard fop build process
Comment 18 Glenn Adams 2012-04-30 00:14:40 UTC
batch transition resolved+wontfix to closed+wontfix
Comment 19 Glenn Adams 2012-04-30 00:17:12 UTC
batch transition resolved+wontfix to closed+wontfix; if you believe this remains a bug and can demonstrate it with appropriate input FO file and output PDF file (as applicable), then you may reopen