[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: test if there is a gain



>>>>> "Arnaud" == Arnaud Vandyck <avandyck@gmail.com> writes:

Arnaud> About the gcj ABI, it'd be cool to know the plans of the gcj
Arnaud> devs before putting efforts in packaging java to native ;-)

GCC 4.0 includes the first working version of the BC ABI.  However, we
don't yet promise actual binary compatibility -- we've kept open the
possibility that we made some error and that code compiled BC with 4.0
will have to be recompiled to work with the library shipped with 4.1.

We already know we'll have to change the code we're generating; i.e.,
we've found a couple of bugs.  However, at the moment it looks like we
can remain backward compatible.

4.0 has another limitation, which is that you can't compile from .java
using BC -- you must compile from .class.  For FC4 we just compile all
the jars in a package.  This turns out to be more convenient anyway,
since you don't need to hack the upstream build process.

We've been hoping to promise true binary compatibility starting with
GCC 4.1.  What that means is that, barring a major mistake or change,
if you compile some code BC, you will never have to recompile it
again.  (In practice, of course, you would want to, as presumably
future GCC versions will have improvements you would want to take
advantage of.)

Here's a page explaining the basics of how we're building
applications using BC for FC:

    http://gcc.gnu.org/wiki/How%20to%20BC%20compile%20with%20GCJ

We've compiled at least Eclipse, Tomcat, Ant, and Jonas this way (not
all of these are in FC4).  I've also compiled Derby like this before.

All this stuff works with standard GCC 4.0.  There are a few bugs
whose fixes didn't quite make the release; these are going in cvs even
now and will show up in 4.0.1.


hope this helps,
Tom



Reply to: