Re: [gcj-eclipse-merge-branch] MinGW ecj: Cross-built ecjx?! (was Re: ecj branch)

[Andi Vajda <andi at osafoundation dot org>]

On Tue, 5 Dec 2006, Tom Tromey wrote:

> > > > > > "Mohan" == Mohan Embar <gnustuff@thisiscool.com> writes:
>
> > > ecj1 (which is what ecjx is called when it is installed) is sort of
> > > like cpp, back in the days when we had a separate preprocessor.  gcj
> > > will invoke ecj1 first, then pass its (class file) output to jc1 for
> > > further compilation.
>
> Mohan> So to paraphrase: ecj1 is target independent and doesn't
> Mohan> produce object code?
>
> Correct.  ecj1 is pure java and it translates .java to .class.
>
> Note that by this I mean that the bytecode bits of ecj1 are platform
> independent.

I've had problems with bytecode and platform independence recently, albeit not 
with ecj1. The issue I've noticed is that when compiling Java Lucene from 
.java to .class to .jar with a non gcj javac such as Apple's, Sun's or 
Blackdown's, using these bits to then compile from .jar to .o with gcj, the 
resulting executables will or will not perform correctly depending on where 
the .java compilation took place.

Since the beginning of PyLucene, I've always been able to compile the .java on 
a Powerbook G4 with Apple's javac and use these bits with any gcj 3.4.x 
compiler on any platform I've had it available (Linux, Windows, PPC Mac).

That appears to not be the case with gcj 4.x. When using gcj 4.x, I have to 
compile the .java to .class to .jar on the machine that is later going to 
compile the .jar into .o. More precisely, this is the case with gcj 4.0.2 on 
Intel Mac OS X and with gcj 4.2.0 (recent November snapshot) on Ubuntu Etch 
AMD x86-64.

I've been using a non gcj javac all this time because I've had to apply too 
many patches to the Lucene .java sources to use gcj to compile from .java and 
get an executable that passes all PyLucene unit tests.

I'm very interested to see if replacing the gcj front-end with ecj is going to 
solve these problems...

Thank you for all the great work in that area, the Java Lucene developers are 
eagerly waiting for Java 1.5 support in gcj so that they can allow Java 
1.5-requiring code into their source tree.

Andi..