Both stable eclipse-swt-3.4.1-5.fc10.x86_64.rpm and rawhide eclipse-swt-3.4.1-15.fc11.x86_64.rpm are missing some shared objects which are present in the upstream eclipse-SDK-3.4.1-linux-gtk-x86_64.tar.gz/eclipse/plugins/org.eclipse.swt.gtk.linux.x86_64_3.4.1.v3449c.jar file. Not present in Fedora are libswt-xulrunner-gtk-3449.so, libswt-xpcominit-gtk-3449.so, libcairo-swt.so among others - and these ones seem necessary for various plugins. For one, this prevents the JBoss Tools 3 plugin for Eclipse from working properly; the Visual Page Editor does not initialize with the error message: !ENTRY org.eclipse.ui 4 0 2009-02-06 15:03:03.812 !MESSAGE Unhandled event loop exception !STACK 0 org.eclipse.swt.SWTError: No more handles (java.lang.UnsatisfiedLinkError: no swt-xulrunner-gtk-3449 or swt-xulrunner-gtk in swt.library.path, java.library.path or the jar file) Can we make these .so files build for the Fedora RPM as well? Thanks. For now, as a workaround, I am using the missing shared objects from upstream by putting them in my swt.library.path in the eclipse.ini file.
We'll have to investigate why those aren't getting built, but we're definitely linking against xulrunner and cairo with these .so files: /usr/lib64/eclipse/libswt-mozilla-gtk-3449.so /usr/lib64/eclipse/libswt-cairo-gtk-3449.so
The problem is upstream and it's actually my fault. In https://bugs.eclipse.org/bugs/show_bug.cgi?id=226356 I submitted a patch [1] which added a section to SWT's build.sh [2] to build the browser bindings if xulrunner-devel was present instead of mozilla-devel. The patch has a section that reads: + elif [ x`pkg-config --exists libxul && echo YES` = "xYES" ]; then + MOZILLA_INCLUDES=`pkg-config --cflags libxul` + MOZILLA_LIBS=`pkg-config --libs libxul` + export MOZILLA_INCLUDES + export MOZILLA_LIBS + MAKE_MOZILLA=make_mozilla That last line should probably be make_xulrunner because then make_linux.mak [3] would end up calling that target which generates the libswt-xulrunner .so. There appear to be some xulrunner-specific .o files created but looking at make_linux.mak -- specifically line 249 -- it looks like the rest of the linking done to make our libswt-mozilla is the same. At this point you may be asking yourself why eclipse.org's .so files are named/linked properly in this case. That's because they don't build them as part of their builds using build.sh like we do. I'd be interested to know if symlinking a libswt-xulrunner to libswt-mozilla would suffice for JBDS's requirements. Would you mind giving it a shot? Since we're only shipping xulrunner-devel in Fedora, I wonder if we should just make_xulrunner and add a compatibility symlink for libswt-mozilla. As for libswt-cairo.so I have no idea where that comes from. I'm also not even sure that it's used :) If you have time, you mind filing a bug upstream asking if it's still needed? I could be wrong here but ISTR it is from back when the distros that eclipse.org was supporting didn't have Cairo. It may not longer be necessary. We are definitely linking against cairo as you can see in the koji build log [4] (look for "-o libswt-cairo-gtk-3449"). [1] https://bugs.eclipse.org/bugs/attachment.cgi?id=95418 [2] http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.swt/Eclipse SWT PI/gtk/library/build.sh?revision=1.50&view=markup [3] http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.swt/Eclipse SWT PI/gtk/library/make_linux.mak?revision=1.48&view=markup [4] http://kojipkgs.fedoraproject.org/packages/eclipse/3.4.1/15.fc11/data/logs/i386/build.log
(In reply to comment #2) > I'd be interested to know if symlinking a libswt-xulrunner to libswt-mozilla > would suffice for JBDS's requirements. Would you mind giving it a shot? Since > we're only shipping xulrunner-devel in Fedora, I wonder if we should just > make_xulrunner and add a compatibility symlink for libswt-mozilla. The symlinking did not help; it fails with an UnsatisfiedLinkError exception: !ENTRY org.eclipse.jface 4 2 2009-02-16 15:42:35.388 !MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.jface". !STACK 0 java.lang.UnsatisfiedLinkError: org.eclipse.swt.internal.mozilla.XPCOM.NS_GetComponentManager([J)I at org.eclipse.swt.internal.mozilla.XPCOM.NS_GetComponentManager(Native Method) at org.eclipse.swt.browser.Mozilla.create(Mozilla.java:1016) at org.eclipse.swt.browser.Browser.<init>(Browser.java:118) at org.jboss.tools.vpe.xulrunner.browser.XulRunnerBrowser.<init>(XulRunnerBrowser.java:87) at org.jboss.tools.vpe.xulrunner.editor.XulRunnerEditor.<init>(XulRunnerEditor.java:126) at org.jboss.tools.vpe.editor.mozilla.MozillaEditor$5.<init>(MozillaEditor.java:282) at org.jboss.tools.vpe.editor.mozilla.MozillaEditor.createPartControl(MozillaEditor.java:282) at org.jboss.tools.vpe.editor.VpeEditorPart.createVisualEditor(VpeEditorPart.java:769) . . . This is not too surprising as the two upstream .so files are very different sizes and libswt-xulrunner definitely has more objects in there. > As for libswt-cairo.so I have no idea where that comes from. I'm also not even > sure that it's used :) If you have time, you mind filing a bug upstream asking > if it's still needed? I could be wrong here but ISTR it is from back when the > distros that eclipse.org was supporting didn't have Cairo. It may not longer > be necessary. As far as I can tell after some trial and error, it appears that only libswt-xulrunner-gtk-3449.so is *necessary* at runtime for JBDS to function without crashing (in my very limited coverage testing.) The upstream .so files that I removed without causing a error were: libswt-mozilla-gcc3-gtk-3449.so (not surprising, looks like a compatibility .so) libcairo-swt.so (unsure what this is, need to search upstream a bit) libswt-xpcominit-gtk-3449.so (surprising, probably just didn't hit in my tests)
(In reply to comment #0) > Can we make these .so files build for the Fedora RPM as well? Thanks. For now, > as a workaround, I am using the missing shared objects from upstream by putting > them in my swt.library.path in the eclipse.ini file. As an aside that I haven't been able to figure out after considerable searching and effort: Can I have a user specific eclipse.ini that overrides the system wide file /usr/lib64/eclipse/eclipse.ini when I use Eclipse 3.4+? If so, how?
(In reply to comment #4) > (In reply to comment #0) > > Can we make these .so files build for the Fedora RPM as well? Thanks. For now, > > as a workaround, I am using the missing shared objects from upstream by putting > > them in my swt.library.path in the eclipse.ini file. > > As an aside that I haven't been able to figure out after considerable searching > and effort: Can I have a user specific eclipse.ini that overrides the system > wide file /usr/lib64/eclipse/eclipse.ini when I use Eclipse 3.4+? If so, how? I'm not sure. I'll look into it.
(In reply to comment #4) > Can I have a user specific eclipse.ini that overrides the system > wide file /usr/lib64/eclipse/eclipse.ini when I use Eclipse 3.4+? If so, how? Can you try putting it in ~/.eclipse/org.eclipse.platform_3.4.0*?
I submitted a patch upstream: https://bugs.eclipse.org/bugs/attachment.cgi?id=127709 Let's see what they say before trying it in our builds.
(In reply to comment #6) > (In reply to comment #4) > > Can I have a user specific eclipse.ini that overrides the system > > wide file /usr/lib64/eclipse/eclipse.ini when I use Eclipse 3.4+? If so, how? > > Can you try putting it in ~/.eclipse/org.eclipse.platform_3.4.0*? I noticed a file named ~/.eclipse/org.eclipse.platform_3.4.0_793567567/configuration/eclipse.ini.ignored earlier and tried renaming it eclipse.ini and editing it to my desired startup arguments. It didn't work. The same results if I try the parent directory as you suggested: ~/.eclipse/org.eclipse.platform_3.4.0_793567567. So far I have had to edit the system-wide one in /usr/lib64/eclipse to have an effect.
Then I guess there's no way to have a per-user configuration. I'll ask some upstream people about it when I'm at EclipseCon. Sorry.
I've submitted a build to koji that will hopefully fix this: http://koji.fedoraproject.org/koji/buildinfo?buildID=94349
The build with the changes finished successfully. Could someone who has a use case for the .so files see if it fixes things for them? It looks like the .so files are named as one would expect. Thanks.
It looks like the internal browser is broken with this change. If anyone has time to look into it and figure out what's going wrong, I'd appreciate it. I will not promote this build to F-11.
In case anyone's interested, I'm working on this upstream here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=226356
I've got a build going now with what I hope is a real fix for this: http://koji.fedoraproject.org/koji/taskinfo?taskID=1280756 It builds on the work to get SWT working with XULRunner 1.9.1 beta 3 so it *may* require the F-11 beta or rawhide. Once we've verified that the SWT-XULRunner interaction isn't broken, if you could test that this works for the JBoss Tools case, Naveed, I'd appreciate it.
I verified in my x86_64 F-11 VM that this works. Among others, I see the following files in eclipse-swt: /usr/lib64/eclipse/libswt-xpcominit-gtk-3452.so /usr/lib64/eclipse/libswt-xulrunner-gtk-3452.so I was able to get the welcome screen and start the help system. I'll leave it up to you, Naveed, to close this when you get a chance to verify that it works for you with JBoss Tools. Thanks.
(In reply to comment #14) > It builds on the work to get SWT working with XULRunner 1.9.1 beta 3 so it > *may* require the F-11 beta or rawhide. Once we've verified that the > SWT-XULRunner interaction isn't broken, if you could test that this works for > the JBoss Tools case, Naveed, I'd appreciate it. By renaming (or symlinking) so that Fedora 10 stable Eclipse 3.4.1 sees 3449 (instead of 3452) in the .so file names, things appear to be working well with JBoss Tools 3 Visual Page Editor. Great! (In reply to comment #15) > I'll leave it up to you, Naveed, to close this when you get a chance to verify > that it works for you with JBoss Tools. Thanks. Thanks for all the assistance!