Hello,

A while ago, I wrote:

        Using the following pakages:
 * java-gcj-compat{,-dev} 1.0.69-2
 * ecj, ecj-gcj, libecj-java and libecj-gcj 3.3.0+0728-1
 * libgcj-bc, libgcj8{-1,-1-awt,-jar} 4.2.1-3
 * gcc-4.2-base 4.2.1-3
 * gcj-4.1-base, gcj-4.1, gij-4.1, libgcj7-1 4.1.2-16
 * libgcc1 1:4.2.2-3
eclipse-cdt compiles.

Updating to sid, I reach a point where it no longer compiles:
 * java-gcj-compat 1.0.76-4 sets gcj-4.2 as the default gcj version
 * gcj-4.2, gij-4.2 and libgcj8-* are at version 4.2.1-3

On Sat, Jan 26, 2008 at 05:12:44PM +0100, Michael Koch replied:

I have just tried this with SUN JDK 6, Icedtea, gcj 4.3, jamvm and cacao
with the following result:
* SUN JDK 6: Just works.
* gcj-4.3: No output at all. Returns with exit code 13.
* icedtea: No output at all. Returns with exit code 13. Exactly the same
  as with gcj.
* jamvm: Fails but prints quite some output. Main issue is that jamvm has
  no real JAVA_HOME.
* cacao: Fails but prints some output. Again an issue with an incomplete
  JAVA_HOME provided by cacao.

We made progress on this issue with Michael; it turns out that using
eclipse natively compiled -gcj packages work around the FTBFS, for some
reason.

Michael found out that only eclipse-rcp-gcj is needed, and that deleting
org.eclipse.core.runtime_3.2.0.v20060603.jar.so is enough to make the
compilation fails, while it works when it's there.

So we now have a work-around to compile Eclipse plugins: install
eclipse-rcp-gcj.

What's really weird is that icedtea, even though it does not use -gcj
packages, exhibit the very same behavior.