Re: [Classpathx-discuss] Re: LibxmlJ formalities

[Tom Tromey]

>>>>> "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