xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 39927] - Building FOP with GCJ
Date Wed, 02 Aug 2006 13:48:47 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=39927>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39927





------- Additional Comments From matthew@linuxfromscratch.org  2006-08-02 13:48 -------
(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!

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

Mime
View raw message