Bug 39927

Created attachment 18545 [details]
Log of build failure

Build log captured using `ant -verbose`

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.

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.

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.

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!

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)

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!

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.

(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 '<', '>' and
> '&'.  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.

(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 '<', '>' and
> > '&'.  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.

(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 '<',
'>' and
> > > '&'.  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.

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.

(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!

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 :-(

(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.

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.

gcj is not used by standard fop build process

batch transition resolved+wontfix to closed+wontfix

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