Bug 484453 - eclipse-swt missing some shared objects (e.g. libswt-xulrunner-gtk-3449.so)
eclipse-swt missing some shared objects (e.g. libswt-xulrunner-gtk-3449.so)
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: eclipse (Show other bugs)
10
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Andrew Overholt
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-06 16:15 EST by Naveed Hasan
Modified: 2009-04-21 02:15 EDT (History)
4 users (show)

See Also:
Fixed In Version: 3.4.2-9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-21 02:15:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Naveed Hasan 2009-02-06 16:15:26 EST
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.
Comment 1 Andrew Overholt 2009-02-06 16:20:09 EST
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
Comment 2 Andrew Overholt 2009-02-10 11:43:18 EST
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
Comment 3 Naveed Hasan 2009-02-16 16:20:07 EST
(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)
Comment 4 Naveed Hasan 2009-02-16 16:25:51 EST
(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?
Comment 5 Andrew Overholt 2009-02-16 16:34:19 EST
(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.
Comment 6 Andrew Overholt 2009-03-05 15:29:30 EST
(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*?
Comment 7 Andrew Overholt 2009-03-05 15:43:22 EST
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.
Comment 8 Naveed Hasan 2009-03-05 18:35:13 EST
(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.
Comment 9 Andrew Overholt 2009-03-06 09:26:45 EST
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.
Comment 10 Andrew Overholt 2009-03-16 14:32:33 EDT
I've submitted a build to koji that will hopefully fix this:

http://koji.fedoraproject.org/koji/buildinfo?buildID=94349
Comment 11 Andrew Overholt 2009-03-17 12:06:35 EDT
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.
Comment 12 Andrew Overholt 2009-03-17 12:58:07 EDT
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.
Comment 13 Andrew Overholt 2009-03-20 14:44:06 EDT
In case anyone's interested, I'm working on this upstream here:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=226356
Comment 14 Andrew Overholt 2009-04-06 17:30:00 EDT
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.
Comment 15 Andrew Overholt 2009-04-06 19:24:06 EDT
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.
Comment 16 Naveed Hasan 2009-04-21 02:15:49 EDT
(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!

Note You need to log in before you can comment on or make changes to this bug.