Re: Bug#432541: eclipse-cdt FTBFS with gcj-4.2
Andrew Haley wrote:
> Andrew Haley wrote:
>> 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.
OK, and the *reason* for this is that IPluginDescriptor is loaded not
from eclipse/plugins/org.eclipse.core.runtime_3.3.100.v20070530.jar
but from
eclipse/plugins/org.eclipse.core.runtime.compatibility.registry_3.2.100.v20070316/runtime_registry_compatibility.jar
So, if you ask IPluginDescriptor's class loader to find Plugin it
throws a ClassNotFoundException.
The only files in runtime_registry_compatibility.jar are:
org/eclipse/core/internal/registry/BundleHelper.class
org/eclipse/core/internal/registry/ExtensionHandle.class
org/eclipse/core/internal/registry/ExtensionPointHandle.class
org/eclipse/core/internal/registry/RegistryCompatibilityHelper.class
org/eclipse/core/runtime/IExtension.class
org/eclipse/core/runtime/IExtensionPoint.class
org/eclipse/core/runtime/IPluginDescriptor.class
So, I think I now have enough to write a test case. Two class
loaders, one of which loads a subset of the other's classes. Call
an interface in the class defined by the subset class loader and
see what happens.
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
Andrew Haley wrote:
> 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 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.
--
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
Andrew> To be clear: the two class loaders being checked are those of Andrew> interface org.eclipse.core.runtime.IPluginDescriptor Andrew> and Andrew> class org.eclipse.core.runtime.Platform Andrew> Tromey: are you quite sure we should be checking the class loader Andrew> of the interface type instead of the class loader of the method we're Andrew> invoking? I'm pretty sure. Here is the relevant spec: http://java.sun.com/docs/books/jvms/second_edition/html/ConstantPool.doc.html#73492 Scroll down to section 5.4.3.4, "Interface Method Resolution". As I read it, this describes checking the types resolved by the loader of the calling class against the types resolved by the loader of the interface. For type safety you really have to do both checks, of course. However, I believe that checking the types of the concrete class against the interface it purports to implement is done when linking that class. Tom -- 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
Andrew Haley wrote: 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 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(). To be clear: the two class loaders being checked are those of interface org.eclipse.core.runtime.IPluginDescriptor and class org.eclipse.core.runtime.Platform Tromey: are you quite sure we should be checking the class loader of the interface type instead of the class loader of the method we're invoking? 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 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.
Tom Tromey: opinion, please.
Andrew.
public final class Platform {
...
public static Plugin getPlugin(String id) {
try {
IPluginRegistry registry = getPluginRegistry();
if (registry == null)
throw new IllegalStateException();
IPluginDescriptor pd = registry.getPluginDescriptor(id);
if (pd == null)
return null;
return pd.getPlugin(); // <== This is where the
ClassNotFoundException is thrown
} catch (CoreException e) {
// TODO log the exception
}
return null;
}
--
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
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]
Re: Bug#432541: eclipse-cdt FTBFS with gcj-4.2
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...
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 Sat, Feb 16, 2008 at 10:33:21AM +, Andrew Haley wrote: Michael Koch wrote: On Sat, Feb 16, 2008 at 09:56:18AM +, Andrew Haley wrote: Has anyone actually attempted to debug this? Which code actually calls Runtime.exit()? I tried to debug this but I dont found out from where exit is called with code 13. What went wrong with the debugging? Do you want me to look? I was not able top get proper backtraces. All I found was that exit_group(13) was called. So, no-one has actually tried to debug this. I'm betting it's a bogus version check. What kind of version check do you mean? As far as I'm aware, OSGI bundles are versioned and if an appropriate OSGI bundle version is not found the program exits. That doesnt explain why the build always worked with SUN JDK. It should have failed the same if OSGi versions would be a problem. Wouldn't it? No. Did you try it with OpenJDK (the Sun version with the binary plugs) ? This is an important test. 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 Sat, Feb 16, 2008 at 10:33:21AM +, Andrew Haley wrote: > Michael Koch wrote: > > On Sat, Feb 16, 2008 at 09:56:18AM +, Andrew Haley wrote: > >> Has anyone actually attempted to debug this? Which code actually calls > >> Runtime.exit()? > > > > I tried to debug this but I dont found out from where exit is called > > with code 13. > > What went wrong with the debugging? Do you want me to look? I was not able top get proper backtraces. All I found was that exit_group(13) was called. > >> I'm betting it's a bogus version check. > > > > What kind of version check do you mean? > > As far as I'm aware, OSGI bundles are versioned and if an > appropriate OSGI bundle version is not found the program exits. That doesnt explain why the build always worked with SUN JDK. It should have failed the same if OSGi versions would be a problem. Wouldn't it? 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 Sat, Feb 16, 2008 at 09:56:18AM +, Andrew Haley wrote: Has anyone actually attempted to debug this? Which code actually calls Runtime.exit()? I tried to debug this but I dont found out from where exit is called with code 13. What went wrong with the debugging? Do you want me to look? I'm betting it's a bogus version check. What kind of version check do you mean? As far as I'm aware, OSGI bundles are versioned and if an appropriate OSGI bundle version is not found the program exits. 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 Sat, Feb 16, 2008 at 09:56:18AM +, Andrew Haley wrote: > Has anyone actually attempted to debug this? Which code actually calls > Runtime.exit()? I tried to debug this but I dont found out from where exit is called with code 13. > I'm betting it's a bogus version check. What kind of version check do you mean? 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
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]
Re: Bug#432541: eclipse-cdt FTBFS with gcj-4.2
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?
Regards,
Thomas
--
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
Le samedi 26 janvier 2008 à 17:12 +0100, Michael Koch a écrit : > 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. That's great Michael, because it means it should now be possible to debug this issue from within eclipse itself using icedtea! Regards, Thomas -- 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 Sat, Oct 27, 2007 at 10:17:47PM +0200, Thomas Girard wrote:
> reassign 432541 gcj-4.2
> retitle 432541 gcj-4.2 can no longer compile Eclipse plugins
> merge 432539 432541
> thanks
>
> Hi,
>
> after having slowly updated an etch chroot to a sid one using
> snaphsot.debian.net, I have found that the FTBFS occurs with gcj-4.2,
> and is not related to ecj.
>
> Indeed, 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:
> * 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
>
> With these packages eclipse-cdt no longer compiles.
>
> I'll try to use earlier versions of {gcj,gij}-4.2.
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.
I will investigate more into this.
Cheers,
Michael
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
