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

[Andrew Haley]

Andrew Haley wrote:
> Michael Koch wrote:
>> On Sun, Mar 02, 2008 at 12:01:03PM +0000, Andrew Haley wrote:
>>> Michael Koch wrote:
>>>> On Sun, Mar 02, 2008 at 10:35:28AM +0000, Andrew Haley wrote:
>>>>> And what was the reason?  I need to know.
>>>> !ENTRY org.eclipse.osgi 4 0 2008-03-02 12:38:50.196
>>>> !MESSAGE Application error
>>>> !STACK 1
>>>> java.lang.ClassNotFoundException: org.eclipse.core.runtime.Plugin
>>>>    at
>>>> org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:402)
>>>>
>>>>    at
>>>> org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:347)
>>>>
>>>> make: *** [build-stamp] Fehler 13
>>>>
>>>> The only small strange thing is that org.eclipse.core.runtime.Plugin
>>>> and
>>>> org.eclipse.core.runtime.Platform are in the same Jar. This must be
>>>> some
>>>> OSGi issue. At least I know now where to start debugging.
>>> Oh, right, so you *don't* actually know what the cause of this is. 
>>> Me either, but
>>> I'm debugging it at the moment.
>>
>> Yeah, yesterday I thought it was just a missing jar file. Today I took a
>> closer look at at it...
>>
>>> gcj should not distinguish between natively compiled code and bytecode.
>>> The fact that it makes a difference must be a bug.
>>
>> Sounds like it. Can I somehow help? I know this is a hard case and
>> currently cant think of a simpler testcase.
> 
> OK, I've found it.  The ClassNotFoundException is thrown from a security
> check
> in libgcj.  We are calling Method m1 from method m0, and m1's class loader
> is different from m0's class loader.  We have to check that for every arg
> in m1, the actual type is the same in both m1.loader and m0.loader.
> 
> The method in question is
> org.eclipse.core.runtime.Platform.getPlugin(String), which returns an
> instance of org.eclipse.core.runtime.Plugin.  It gets this
> by calling org.eclipse.core.internal.plugins.PluginDescriptor.getPlugin().
> 
> When we do the security check, we call Platform's class loader to ask it
> to loadClass("org.eclipse.core.runtime.Plugin") and it throws a
> ClassNotFoundException.

OK, I've discovered some more.  The class loader that's throwing the
exception is a
org.eclipse.osgi.framework.internal.core.BundleLoader, and
it's being asked to find org.eclipse.core.runtime.Plugin.  Now, this
is where it gets really interesting.

org.eclipse.core.runtime.Plugin is defined in
eclipse/plugins/org.eclipse.core.runtime_3.3.100.v20070530.jar,
along with a few other classes, including
org.eclipse.core.runtime.IPluginDescriptor and
org.eclipse.core.runtime.Platform.

*but*

IPluginDescriptor's class loader is not able to find
org.eclipse.core.runtime.Plugin.

Andrew.