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.

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.

by calling org.eclipse.core.internal.plugins.PluginDescriptor.getPlugin().