Thomas Girard wrote:
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.
Has anyone actually attempted to debug this? Which code actually calls
Runtime.exit()?
I'm betting it's a bogus version check.
Andrew.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
