[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Classpathx-discuss] Re: LibxmlJ formalities
From: |
Tom Tromey |
Subject: |
Re: [Classpathx-discuss] Re: LibxmlJ formalities |
Date: |
26 Feb 2003 16:54:36 -0700 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
>>>>> "Julian" == Julian Scheid <address@hidden> writes:
Julian> First of all, note that I am aware of gcj's bytecode
Julian> compilation modus operandi, but with 'compiling with gcj' I
Julian> generally intend to say native compilation. Bytecode vs native
Julian> compilation may be the reason why it works in rhug and doesn't
Julian> work for me.
rhug compiles everything from source to native, as far as I know.
But see below.
Julian> Also I didn't try that hard to get Xalan running, so my
Julian> statement may have been a little rash. I have only tried to
Julian> add xalan.jar to the gcj command line, and to use Xalan
Julian> bytecode via a ClassLoader from a gcj- compiled executable,
Julian> both of which failed.
Ok. Sometimes the rhug maintainers add special hacks to a package to
let it compile with gcj. gcj's front end has some irritating bugs :-(
Sometimes I gather getting something into rhug is quite painful.
Possibly xalan falls into this category. Or maybe rhug has an older
version and the newer ones make life harder for gcj. I don't know.
Julian> But meanwhile I learned that gcj generally doesn't work well when fed
Julian> jars, and generally _does_ work well when fed only .java source codes.
That's interesting. Do you remember what problems you've had?
Usually I find that compiling from .java is worse, since the parser
(well, really the analysis phase) has a lot of bugs and oddities. I
know there are some bugs reading bytecode, though. I'm wondering if
you ran into those, or if you've found new ones...
Also it depends a lot on how the .jar was made. Recently I've
discovered that both jikes and the Eclipse java compiler generate
bytecode that gcj's verifier erroneously rejects :-(. The Sun (and
IBM) javac seems not to do this. (I'm more or less actively working
on fixing this set of bugs.)
Julian> Can you point me to more information on gcj's handling of sources,
Julian> classes and jars specified on the command line? The gcc docs are a
Julian> little sparse on Java-specific details.
There's really only the stuff in gcj.texi. Here's what I found:
http://gcc.gnu.org/onlinedocs/gcc-3.2.2/gcj/
Command-line stuff in particular:
http://gcc.gnu.org/onlinedocs/gcc-3.2.2/gcj/Input-and-output-files.html#Input%20and%20output%20files
http://gcc.gnu.org/onlinedocs/gcc-3.2.2/gcj/Input-Options.html#Input%20Options
Anyway, just because xalan exists, it doesn't affect your work, I
think. A high performance implementation is cool, especially since it
wraps a library that every Linux distro is already going to ship.
Tom
- [Classpathx-discuss] Re: LibxmlJ formalities, (continued)
- [Classpathx-discuss] Re: LibxmlJ formalities, Nic Ferrier, 2003/02/25
- [Classpathx-discuss] Re: LibxmlJ formalities, Julian Scheid, 2003/02/25
- Re: [Classpathx-discuss] Re: LibxmlJ formalities, Nic Ferrier, 2003/02/25
- Re: [Classpathx-discuss] Re: LibxmlJ formalities, Julian Scheid, 2003/02/26
- Re: [Classpathx-discuss] Re: LibxmlJ formalities, Nic Ferrier, 2003/02/26
- Re: [Classpathx-discuss] Re: LibxmlJ formalities, Julian Scheid, 2003/02/26
- Re: [Classpathx-discuss] Re: LibxmlJ formalities, Nic Ferrier, 2003/02/26
- Re: [Classpathx-discuss] Re: LibxmlJ formalities, Julian Scheid, 2003/02/26
- Re: [Classpathx-discuss] Re: LibxmlJ formalities, Tom Tromey, 2003/02/26
- [Classpathx-discuss] Re: LibxmlJ formalities, Julian Scheid, 2003/02/26
- Re: [Classpathx-discuss] Re: LibxmlJ formalities,
Tom Tromey <=
- Re: [Classpathx-discuss] Re: LibxmlJ formalities, Julian Scheid, 2003/02/26
- Re: [Classpathx-discuss] Re: LibxmlJ formalities, Nic Ferrier, 2003/02/27
- Re: [Classpathx-discuss] Re: LibxmlJ formalities, Tom Tromey, 2003/02/27
Re: [Classpathx-discuss] Re: LibxmlJ formalities, David Brownell, 2003/02/25