swt fails to build xulrunner support with firefox 4 / xulrunner 2 installed. Reproducible: Always
Created attachment 245284 [details] build.log
Perhaps you could supply the additional information requested at the end of that log -- so far you've just got the build log: If you need support, post the output of 'emerge --info =dev-java/swt-3.6', the complete build log and the output of 'emerge -pqv =dev-java/swt-3.6'.
Created attachment 245508 [details] emerge --info
Created attachment 245509 [details] emerge -pvq
Reading bug #293396 comment #25 xulrunner-2 doesnt support Java at all, so we may need to restict versions. @mozilla please advise.
another thing i just realized (i dont know if its connected). eclipse (from the HP) wont run with xulrunner either as in bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=323913 since swt is part of eclipse this might be interesting, too
(In reply to comment #5) > Reading bug #293396 comment #25 xulrunner-2 doesnt support Java at all, so we > may need to restict versions. > > @mozilla please advise. > You need to restrict, java is gone in xulrunner-2.0 and will not be returning any time soon.
(In reply to comment #7) Can we request slotting if it's not already slotted for 2.0?
(In reply to comment #5) > Reading bug #293396 comment #25 xulrunner-2 doesnt support Java at all, so we > may need to restict versions. > Yes but swt doesn't require the component of xulrunner that Java enables.
(In reply to comment #8) > (In reply to comment #7) > Can we request slotting if it's not already slotted for 2.0? > Slotting between 1.9 and 2.0 is not gonna make the job any easier. Most packages will need to patch for pkg-config to check for one version or another if we slot.
(In reply to comment #10) > (In reply to comment #8) > > (In reply to comment #7) > > Can we request slotting if it's not already slotted for 2.0? > > > > Slotting between 1.9 and 2.0 is not gonna make the job any easier. Most > packages will need to patch for pkg-config to check for one version or another > if we slot. > After looking at the ebuild, why is webkit not avaliable? This is rather a simple fix add webkit useflag and restrict xulrunner useflag to a 1.9.x version instead of depending on the slot.
Created attachment 247978 [details, diff] swt-3.6 webkit support ... ... and hardwire xulrunner version to '1.9*' (In reply to comment #11) > After looking at the ebuild, why is webkit not avaliable? This is rather a > simple fix add webkit useflag and restrict xulrunner useflag to a 1.9.x version > instead of depending on the slot. Because I did not do the patch yet?! ;) Testcase: Vuze shows the ChangeLog at startup after upgrade. ( That does use the code, doesn't it? )
(In reply to comment #12) > > > Testcase: Vuze shows the ChangeLog at startup after upgrade. > ( That does use the code, doesn't it? ) > Try this: https://overlays.gentoo.org/svn/proj/java/testcases/dev-java/swt
That testcase needs this java property set to work:'-Dorg.eclipse.swt.browser.UseWebKitGTK=true'No idea where to put this.
according to an eclipse bug i filed this should be put into eclipse.ini https://bugs.eclipse.org/bugs/show_bug.cgi?id=323913
Well, that would be for the Eclipse IDE. The other dependent application is Vuze. Vuze could write it into its gentoo.config:JAVA_OPTIONS parameter. Any other application to fix? Setting the parameter by useflag would be okay I guess?
I tried the webkit support but it crashed horribly here so I gave up and just restricted the xulrunner dep to 1.9. Hope 3.7 works better.
Hello - on amd64 and in my overlay I've just commented out the following as seems to have been a pre-3.5 bug workaround; # # upstream ships libswt-xulrunner*.so even though the build.sh $ # # build it anymore... missing this file leads to another instan$ # # of bug #234934 so we build it too # einfo "Building the xulrunner component against xulrunner-1.9" # # export XULRUNNER_INCLUDES="${MOZILLA_INCLUDES}" # export XULRUNNER_LIBS="${MOZILLA_LIBS}" # # ${make} make_xulrunner || die "Failed to build xulrunner suppor$ # # ${make} make_xpcominit || die "Failed to build xpcominit suppor$ and changed the xulrunner dependancy to the slot. Seems to build against xulrunner 2 and yet to see an issue myself... (use Vuze etc...)
(In reply to comment #10) > Slotting between 1.9 and 2.0 is not gonna make the job any easier. Most > packages will need to patch for pkg-config to check for one version or another > if we slot. How many packages would actually need 1.9 specifically? Couldn't 2.0 continue using the pkg-config name of "libxul" (so mostly everything would continue to work unchanged) and 1.9 be patched to have a pkg-config name of "libxul-1.9"? Then only packages like SWT that need 1.9 specifically would need to have their build systems patched w.r.t. pkg-config. As long as xulrunner 2.0 is in the same slot as xulrunner 1.9, we can't have SWT 3.6.x and Firefox 4 installed at the same time.
*** Bug 361275 has been marked as a duplicate of this bug. ***
(In reply to comment #18) > Hello - on amd64 and in my overlay I've just commented out the following as > seems to have been a pre-3.5 bug workaround; > and changed the xulrunner dependancy to the slot. Seems to build against > xulrunner 2 and yet to see an issue myself... (use Vuze etc...) You say you have embedded browser working after these changes? (e.g. the "vuze hd network" window has content) as I doubt so. What you did could easily be achieved by disabling xulrunner USE flag for swt in /etc/portage/package.use (In reply to comment #19) > As long as xulrunner 2.0 is in the same slot as xulrunner 1.9, we can't have > SWT 3.6.x and Firefox 4 installed at the same time. Same as above, just disable the USE flag. Vuze will still work, sans some (less useful) features :)
Created attachment 268463 [details, diff] swt-3.6.2.patch I bumped the 3.6.1 ebuild to 3.6.2 and fixed some errors I spotted in it. The result is that I can sucessfully run the example (see comment 13). Following things changed: 1.) The bump 2.) Fixed download URI for PPC64 3.) Added webkit support 4.) Added dynamic modifiation of the manifest (requires updated manifest file)
Created attachment 268465 [details, diff] swt-3.6.2-manifest.patch This is the necessary addition to the manifest file.
(In reply to comment #23) > Created attachment 268465 [details, diff] > swt-3.6.2-manifest.patch > > This is the necessary addition to the manifest file. I forgot to mention: In runtest.sh one still needs 'gjl_java_args="-Dorg.eclipse.swt.browser.UseWebKitGTK=true"'
One sidenote: I tried backporting this to swt-3.5.2 but unfortunately the 3.5 series does not have webkit support at all.
I've applied your patch to the swt ebuild in my overlay (dustin). I've also tested it with Eclipse 3.6.2 (also in my overlay). To get Eclipse to use WebKitGTK instead of xulrunner, you need to add the following line to the bottom of /etc/eclipserc-3.6: VM_ARGS=-Dorg.eclipse.swt.browser.UseWebKitGTK=true Now I have a working Eclipse *and* Firefox 4! Thanks for your efforts getting this to work.
The build fails with newer webkit: x86_64-pc-linux-gnu-gcc -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=both -Wl,--sort -common -shared -fPIC -o libswt-webkit-gtk-3659.so swt.o webkit.o webkit_struct s.o webkit_stats.o -lwebkit-1.0 /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/bin/ld: c annot find -lwebkit-1.0 collect2: ld returned 1 exit status # ls /usr/lib/libwebkitgtk-1.0.so* /usr/lib/libwebkitgtk-1.0.so /usr/lib/libwebkitgtk-1.0.so.0.7.0 /usr/lib/libwebkitgtk-1.0.so.0
Any news?
using swt from voyageur overlay, i've noticed the failure in comment27 can be fixed by changing:: WEBKITLIBS = -lwebkit-1.0 to:: WEBKITLIBS = -lwebkitgtk-1.0 in:: /var/tmp/portage/dev-java/swt-3.6.2/work/make_linux.mak
Created attachment 277703 [details] webkit-gtk 1.4 patch after upgrade to webkit-gtk 1.4, WebKitGTK is binary-incompatible between its 1.2 and 1.4 releases, so swt has separate libraries compiled against each. Apply this patch in src_unpack() {}: epatch "${FILESDIR}"/swt-3.6.2-webkit.patch
Fixed in 3.7.1 where xulrunner flag is removed altogether. Thanks.
*** Bug 392493 has been marked as a duplicate of this bug. ***
