Bug#432541: eclipse-cdt FTBFS with gcj-4.2

[Andrew Haley]

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.