From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7 Description of problem: Eclipse crashes on startup when Sun's java from jdk1.5.0_06 is the preferred Java on the system. This happens even when bug #174612 workaround for x86_64 systems is applied (i.e. disable mozilla support by renaming /etc/gre.d/gre64.conf). This is a compatibility bug involving eclipse-platform-3.1.1-1jpp_1fc.FC4.4 and Sun's jdk-1_5_0_06-nb-4_1-linux-ml.bin package. Downgrading java to java-1.4.2-gcj-compat-1.4.2.0-40jpp_31rh.FC4.2 makes the bug go away, but this isn't always desirable. Version-Release number of selected component (if applicable): eclipse-platform-3.1.1-1jpp_1fc.FC4.4 How reproducible: Always Steps to Reproduce: 1. Install Sun's Java package jdk1.5.0_06 2. Make Sun's Java the preferred java on the system 3. Remove ~/workspace and ~/.eclipse, then start eclipse Actual Results: Crash. Expected Results: No crash. Additional info: This eclipse crash leaves a log in ~/workspace/.metadata/.log: !SESSION 2005-12-09 03:04:41.828 ----------------------------------------------- eclipse.buildId=M20050929-0840 java.version=1.5.0_06 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US Command-line arguments: -os linux -ws gtk -arch x86_64 -data ~/workspace !ENTRY org.eclipse.osgi 2005-12-09 03:04:48.63 !MESSAGE Application error !STACK 1 java.lang.UnsatisfiedLinkError: ~/.eclipse/org.eclipse.platform_3.1.1/configuration/org.eclipse.osgi/bundles/86/1/.cp/libswt-pi-gtk-3139.so: ~/.eclipse/org.eclipse.platform_3.1.1/configuration/org.eclipse.osgi/bundles/86/1/.cp/libswt-pi-gtk-3139.so: cannot open shared object file: No such file or directory at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1751) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1660) at java.lang.Runtime.loadLibrary0(Runtime.java:822) at java.lang.System.loadLibrary(System.java:992) at org.eclipse.swt.internal.Library.loadLibrary(Library.java:123) at org.eclipse.swt.internal.gtk.OS.<clinit>(OS.java:19) at org.eclipse.swt.internal.Converter.wcsToMbcs(Converter.java:63) at org.eclipse.swt.internal.Converter.wcsToMbcs(Converter.java:54) at org.eclipse.swt.widgets.Display.<clinit>(Display.java:122) at org.eclipse.ui.internal.Workbench.createDisplay(Workbench.java:381) at org.eclipse.ui.PlatformUI.createDisplay(PlatformUI.java:155) at org.eclipse.ui.internal.ide.IDEApplication.createDisplay(IDEApplication.java:128) at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:79) at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:226) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:376) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:163) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.eclipse.core.launcher.Main.invokeFramework(Main.java:334) at org.eclipse.core.launcher.Main.basicRun(Main.java:278) at org.eclipse.core.launcher.Main.run(Main.java:973) at org.eclipse.core.launcher.Main.main(Main.java:948) Checking the supposedly missing shared library, I find no problems: $ file ~/.eclipse/org.eclipse.platform_3.1.1/configuration/org.eclipse.osgi/bundles/86/1/.cp/libswt-pi-gtk-3139.so ~/.eclipse/org.eclipse.platform_3.1.1/configuration/org.eclipse.osgi/bundles/86/1/.cp/libswt-pi-gtk-3139.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped Therefore, something else is amiss.
Hmm. I have no idea what's going on here. I test with Sun's JVM every once in a while and it works fine for me. I don't have an x86_64 box to try it on, though, so it could be an arch-specific issue. That said, we only "support" running with the free stuff we ship (gij, libgcj, gcj). I'm wondering why the .sos are actual files and not extracted (and symlinked) like they are here. We extract them at build time using our FileInitializer stuff.
This bug is filed against FC4 which is no longer supported. Please re-test with FC5 or FC6 and reopen the bug if the problem still exists. Thanks.