Bugzilla Bug 234934

https://overlays.gentoo.org/svn/proj/java/testcases/dev-java/swt

$ ./runtest2.sh 3.4
compiling...
Running...
Calling: gjl --package swt-3.4 --get-args --get-vm
Using:
Running: exec java  -classpath .:/usr/share/swt-3.4/lib/swt.jar
-Djava.library.path=/usr/lib:/lib:/usr/lib  Snippet128  3.4
Exception in thread "main" org.eclipse.swt.SWTError: No more handles
[MOZILLA_FIVE_HOME='/usr/lib/xulrunner-1.9'] (java.lang.UnsatisfiedLinkError:
no swt-mozilla-gtk-3448 or swt-mozilla-gtk in swt.library.path,
java.library.path or the jar file)
        at org.eclipse.swt.SWT.error(Unknown Source)
        at org.eclipse.swt.browser.Mozilla.create(Unknown Source)
        at org.eclipse.swt.browser.Browser.<init>(Unknown Source)
        at Snippet128.main(Snippet128.java:58)
Caused by: java.lang.UnsatisfiedLinkError: no swt-mozilla-gtk-3448 or
swt-mozilla-gtk in swt.library.path, java.library.path or the jar file
        at org.eclipse.swt.internal.Library.loadLibrary(Unknown Source)
        at org.eclipse.swt.internal.Library.loadLibrary(Unknown Source)
        ... 3 more

Affects azureus - the dashboard screen says loading... infinitely, as mentioned
in bug 229061.

Strange bug, the file it can't find is there:
/usr/lib/libswt-mozilla-gtk-3448.so
swt-3.4_pre6-r1 is fine

Hi,
Please, take in consideration that this bug is resolved with swt 3.5.
So i think we can resolve it making a new ebild for the new (not well tested)
version.
I'm running too much? :)

Please try the 3.4-r1 I just added to tree. Seems to have helped on my amd64.
On x86 it crashes but so does the upstream bundled version.

Hi,
I've tried 3.4-r1 without success.
Same problem than before on my amd64.
Sorry.

I have to say that swt 3.430 provided in the vuze's package works greatly
inside the package itself.
If you download it from
http://kent.dl.sourceforge.net/sourceforge/azureus/Vuze_3.1.1.0_linux-x86_64.tar.bz2
or any other sourceforge's mirror, untar it and then launch azureus script it
is ok.
So i copied the swt.jar v 3.430 from this package to my /usr/share/swt-3.4/lib,
and it was working greatly.
I want to repeat: it was working without any problem, without any error.
But after i made some "crossed tests" (can i say it?) it does not work anymore.
And really i don't know why, it does not have any sense.
I unmerged and then riemerged xulrunner,swt,azureus... There's no solution...
Now the only thing that works is swt 3.5.
Any idea about this?

P.S.: If you make the opposite process (take the compiled swt, extract it and
copy in it all the libswt* libraries from /usr/lib64, than recompress in zip
and rename in jar. Take the obtained swt.jar and copy it into the vuze's
package) and the you launch azureus script it will say that swt.jar isn't for
amd64. 
Maybe it can help :)

(In reply to comment #1)
> Hi,
> Please, take in consideration that this bug is resolved with swt 3.5.
> So i think we can resolve it making a new ebild for the new (not well tested)
> version.
> I'm running too much? :)
> 

Where did you find swt-3.5? The swt main page says nothing about this version.

http://download.eclipse.org/eclipse/downloads/drops/S-3.5M1-200808071402/linPlatform.php

I fixed this test and azureus-3.1.1.0 (vuze gui - browser loading issue) by
adding a rpath entry to the linker like this:

import ... multilib
...
export XULRUNNER_LIBS="-Wl,-R/usr/$(get_libdir)/xulrunner-1.9 $(pkg-config
libxul --libs)"


Looks like xulrunner pkgconfig file needs a fix. The rpath entry for nspr is
there. :)

(In reply to comment #7)
> I fixed this test and azureus-3.1.1.0 (vuze gui - browser loading issue) by
> adding a rpath entry to the linker like this:
> 
> import ... multilib
> ...
> export XULRUNNER_LIBS="-Wl,-R/usr/$(get_libdir)/xulrunner-1.9 $(pkg-config
> libxul --libs)"
> 
> 
> Looks like xulrunner pkgconfig file needs a fix. The rpath entry for nspr is
> there. :)

Hmm that looks more like a workaround to me, because it should not hardcode
specific path - swt is selecting it runtime. But good idea to check for
differences between upstream build and ours.

Some more notes after some testing with help of Serkan:
- there are actually two similar instances of this problem, one cannot find
swt-mozilla-gtk-3448 and one cannot find swt-xulrunner... so one has to check
carefully
- MOZILLA_FIVE_HOME seems to be just a fallback nowadays. swt either finds a
gecko itself using the descriptors in /etc/gre.d/ and override is done with a
java system property - see http://www.eclipse.org/swt/faq.php#specifyxulrunner
- by just renaming the 3.4_pre6 to 3.4, swt is built against xulrunner-1.8 and
produces the libswt-xulrunner... library too. However this worked for Serkan
(his error message was about libswt-xulrunner) but not me. It's strange that
although the 3.4-r1 ebuild basically copies the upstream bundled build script
and doesn't produce the libswt-xulrunner, upstream binary bundles include it.

If you export XULRUNNER_LIBS and XULRUNNER_INCLUDES and add the xulrunner
target it will build the xulrunner library. At least my local version does.

Since xulrunner is the only option it is just fine until swt fixes its browser
detection.

Created an attachment (id=164951) [edit]
patch for the 3.4-r1 ebuild

Here's a patch against current 3.4-r1 ebuild that does the workaround in
comment #7.

OK, applied comment 10 and also comment 9 so we ship all files that upstream
does. It's in swt-3.4-r2 in CVS. I'll better let this stay open for a while...

I am on x86 and it's working properly now. Thank you for your work!

AMD 64 and everything is ok. Good job.

Thanks for testing, marking FIXED.