| Summary: | dev-java/swt-3.4 embedded xulrunner fails to find swt-mozilla-gtk-3448 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Vlastimil Babka (Caster) (RETIRED) <caster> |
| Component: | [OLD] Java | Assignee: | Java team <java> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | h.mth, lucazorzo, thomasa88 |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | patch for the 3.4-r1 ebuild | ||
|
Description
Vlastimil Babka (Caster) (RETIRED)
2008-08-16 15:42:30 UTC
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. 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 attachment 164951 [details, diff] 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. |