Re: Bug#432541: eclipse-cdt FTBFS with gcj-4.2
Andrew Haley wrote: There are areas where compliant jvms might behave differently. For example, the exact time when dependent classes are loaded isn't defined. Maybe at class initialization time, maybe later. All the the spec requires is that ClassNotFoundExceptions aren't raised until classes are referred to. So, it is possible that Eclipse requires some precise semantics of class loading beyond what is strictly required by the spec. Maybe compiled code loads classes earlier than interpreted code, and maybe *the effective classpath has changed* by the time gij tries to load org.eclipse.core.runtime.Plugin. And, in turn, this means that potentially the same VM may behave differently in interpreted and compiled mode... Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#432541: eclipse-cdt FTBFS with gcj-4.2
Michael Koch wrote: On Sun, Mar 02, 2008 at 12:01:03PM +, Andrew Haley wrote: Michael Koch wrote: On Sun, Mar 02, 2008 at 10:35:28AM +, 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 don't think so. My plan is to add a lot of class loader tracing code to libgcj, and I will then trap at the point where compiled succeeds but interpreted doesn't. There are areas where compliant jvms might behave differently. For example, the exact time when dependent classes are loaded isn't defined. Maybe at class initialization time, maybe later. All the the spec requires is that ClassNotFoundExceptions aren't raised until classes are referred to. So, it is possible that Eclipse requires some precise semantics of class loading beyond what is strictly required by the spec. Maybe compiled code loads classes earlier than interpreted code, and maybe *the effective classpath has changed* by the time gij tries to load org.eclipse.core.runtime.Plugin. Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#432541: eclipse-cdt FTBFS with gcj-4.2
On Sun, Mar 02, 2008 at 12:01:03PM +, Andrew Haley wrote: > Michael Koch wrote: >> On Sun, Mar 02, 2008 at 10:35:28AM +, 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. Cheers, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#432541: eclipse-cdt FTBFS with gcj-4.2
Michael Koch wrote: On Sun, Mar 02, 2008 at 10:35:28AM +, 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. gcj should not distinguish between natively compiled code and bytecode. The fact that it makes a difference must be a bug. Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#432541: eclipse-cdt FTBFS with gcj-4.2
On Sun, Mar 02, 2008 at 10:35:28AM +, 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) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:83) at java.lang.ClassLoader.loadClass(ClassLoader.java:377) at org.eclipse.core.runtime.Platform.getPlugin(Platform.java:737) at org.eclipse.core.internal.preferences.legacy.InitLegacyPreferences.init(InitLegacyPreferences.java:43) at org.eclipse.core.internal.preferences.PreferenceServiceRegistryHelper.applyRuntimeDefaults(PreferenceServiceRegistryHelper.java:146) at org.eclipse.core.internal.preferences.PreferencesService.applyRuntimeDefaults(PreferencesService.java:337) at org.eclipse.core.internal.preferences.DefaultPreferences.applyRuntimeDefaults(DefaultPreferences.java:162) at org.eclipse.core.internal.preferences.DefaultPreferences.loadDefaults(DefaultPreferences.java:231) at org.eclipse.core.internal.preferences.DefaultPreferences.load(DefaultPreferences.java:227) at org.eclipse.core.internal.preferences.EclipsePreferences.create(EclipsePreferences.java:307) at org.eclipse.core.internal.preferences.EclipsePreferences.internalNode(EclipsePreferences.java:543) at org.eclipse.core.internal.preferences.DefaultPreferences.node(DefaultPreferences.java:149) at org.eclipse.core.internal.preferences.legacy.PreferenceForwarder.getDefaultPreferences(PreferenceForwarder.java:138) at org.eclipse.core.internal.preferences.legacy.PreferenceForwarder.getString(PreferenceForwarder.java:644) at org.eclipse.ant.core.AntCorePreferences.restoreAntHome(AntCorePreferences.java:284) at org.eclipse.ant.core.AntCorePreferences.restoreCustomObjects(AntCorePreferences.java:191) at org.eclipse.ant.core.AntCorePreferences.(AntCorePreferences.java:157) at org.eclipse.ant.core.AntCorePlugin.setRunningHeadless(AntCorePlugin.java:232) at org.eclipse.ant.core.AntRunner.run(AntRunner.java:473) at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:78) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:92) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:68) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:400) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:177) at java.lang.reflect.Method.invoke(natMethod.cc:205) at org.eclipse.core.launcher.Main.invokeFramework(Main.java:336) at org.eclipse.core.launcher.Main.basicRun(Main.java:280) at org.eclipse.core.launcher.Main.run(Main.java:977) at org.eclipse.core.launcher.Main.main(Main.java:952) 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. Cheers, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#432541: eclipse-cdt FTBFS with gcj-4.2
Michael Koch wrote:
On Fri, Feb 15, 2008 at 11:50:38PM +0100, 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.
Any idea on this?
I'm a bit ashamed. The solution was quiet simple. Added "-consolelog" to
the arguments revealed the reason for this (and for some crashes of
eclipse). I will fix that bug in eclipse packaging. This really makes me
wonder why SUN JDK worked...
And what was the reason? I need to know.
Andrew.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
