Community
Participate
Working Groups
I've added a block to build.sh to build the mozilla bindings against xulrunner's pkg-config file, libxul.pc. I'll attach the patch.
Created attachment 95418 [details] Patch Patch adding the block checking for libxul.pc.
Thanks for the patch! Committed to the gtk and motif streams > 0410.
Created attachment 127709 [details] if xulrunner: make_mozilla -> make_xulrunner I think I made a mistake with my original patch. If we find XULRunner development libraries, we want to make_xulrunner and not make_mozilla, right?
Re-opening.
makes sense, released > 20090313
I just ran a build of Eclipse SDK 3.4.2 with this patch. It built fine and I got the xulrunner .so files. The internal browser no longer works, though: /usr/lib64/xulrunner-1.9'] (java.lang.UnsatisfiedLinkError: no swt-mozilla-gtk-3452 or swt-mozilla-gtk in swt.library.path, java.library.path or the jar file) org.eclipse.swt.SWTError: No more handles Any thoughts, Grant? Thanks.
So it thinks that it wants the swt-mozilla lib at runtime, not the swt-xulrunner one, which is unexpected because I'd assume that your OS has a xulrunner available for it to find. What does running http://www.eclipse.org/swt/faq.php#printmozillapath write to stdout?
(In reply to comment #7) > So it thinks that it wants the swt-mozilla lib at runtime, not the > swt-xulrunner one, which is unexpected because I'd assume that your OS has a > xulrunner available for it to find. Yeah, I'm using Firefox which is using XULRunner right now :) It's all in /usr/lib64/xulrunner-1.9 AFAICT. > What does running > http://www.eclipse.org/swt/faq.php#printmozillapath write to stdout? >>>Snippet creating SWT.MOZILLA-style Browser >>>This failed with the following error: org.eclipse.swt.SWTError: No more handles [Could not detect registered XULRunner to use] at org.eclipse.swt.SWT.error(SWT.java:3803) at org.eclipse.swt.browser.Mozilla.create(Mozilla.java:327) at org.eclipse.swt.browser.Browser.<init>(Browser.java:118) at DisplayMozillaVersion.main(DisplayMozillaVersion.java:13) Snippet creating SWT.NONE-style Browser >>>This failed too, with the following error: org.eclipse.swt.SWTError: No more handles [Unknown Mozilla path (MOZILLA_FIVE_HOME not set)] at org.eclipse.swt.SWT.error(SWT.java:3803) at org.eclipse.swt.browser.Mozilla.create(Mozilla.java:339) at org.eclipse.swt.browser.Browser.<init>(Browser.java:118) at DisplayMozillaVersion.main(DisplayMozillaVersion.java:20)
> [Could not detect registered XULRunner to use] So that's why it wants the mozilla library anyways. I assume you're running 64-bit eclipse? If you're running 32-bit eclipse then it's probably finding your 64-bit xulrunner, trying to use it, then running away when it fails. Or alternatively, if you are running 64-bit eclipse, could it be finding a 32-bit xulrunner somewhere else on your OS and failing similarly? Or, is it possible that your xulrunner isn't properly registered on your OS? Does executing xulrunner --register-global change anything?
(In reply to comment #9) > > [Could not detect registered XULRunner to use] > > So that's why it wants the mozilla library anyways. Hmm. > I assume you're running 64-bit eclipse? Yes. > Or alternatively, if you are running 64-bit eclipse, could it be finding a > 32-bit xulrunner somewhere else on your OS and failing similarly? I only have a system-wide 64-bit xulrunner installed: $ which xulrunner /usr/bin/xulrunner $ rpm -qf `!!` rpm -qf `which xulrunner` xulrunner-1.9.0.6-1.fc10.x86_64 > Or, is it possible that your xulrunner isn't properly registered on your OS? > Does executing xulrunner --register-global change anything? It doesn't appear to. I get the same results after running that as both my user and root.
It's difficult to know what's happening then, it sounds like it should find the xulrunner. I think the best thing to do would be to set a breakpoint. Steps: - retrieve swt from cvs: http://www.eclipse.org/swt/cvs.php - put a breakpoint at the beginning of Mozilla.create() - run http://www.eclipse.org/swt/faq.php#printmozillapath , hit the breakpoint Mozilla creation/initialization happens at the beginning of Mozilla.create(). It's a long ugly method, but I think the comments spell out what's happening, it's just a bunch of different attempts that are made to find a usable gre.
(In reply to comment #11) > - put a breakpoint at the beginning of Mozilla.create() > - run http://www.eclipse.org/swt/faq.php#printmozillapath , hit the breakpoint > > Mozilla creation/initialization happens at the beginning of Mozilla.create(). > It's a long ugly method, but I think the comments spell out what's happening, > it's just a bunch of different attempts that are made to find a usable gre. It looks like it's not finding libswt-xpcominit-gtk-<version>. Funny though, 'cause that file didn't exist when I built with make_mozilla either. In fact, the files in both cases are the same except for the naming: libswt-mozilla-gtk-3452.so -> libswt-xulrunner-gtk-3452.so I'll see if I can figure out how this works with the former and what's different with the latter.
Created attachment 129281 [details] look for swt-xulrunner when MOZILLA_FIVE_HOME found (In reply to comment #12) > I'll see if I can figure out how this works with the former and what's > different with the latter. It looks like it was just a simple case of not looking for swt-xulrunner when MOZILLA_FIVE_HOME has been picked up. See attached patch for one possible fix.
If swt's xpcominit lib is not there then this is the problem, this is what's needed to magically detect a xulrunner at runtime. The solution should be whatever causes this lib to be built. swt's mozilla and xulrunner libraries should be quite similar (but not identical) to each other.
I'm confused as to where the problem lies. If I alter build.sh to force it to call both make_xulrunner *and* make_xpcominit, my build succeeds but the test program fails with: symbol lookup error: /home/overholt/workspace/org.eclipse.swt.gtk.linux.x86_64/libswt-xpcominit-gtk-3537.so: undefined symbol: XPCOMGlueStartup If I modify libxul.pc (the pkg-config file from xulrunner-devel) to change this line: Libs: -L${sdkdir}/sdk/lib -lxpcomglue_s -lxul -lxpcom to be like this: Libs: -L${sdkdir}/sdk/lib -lxpcomglue_s -lxul -lxpcom -lxpcomglue as seen at [1], rebuild, and re-run, things work. [1] http://bugs.gentoo.org/241400
When we build swt's libs the following vars are set, maybe these would help? They're from the swt gtk fragment's buildLibraries_rhel4.csh file. setenv MOZILLA_INCLUDES "-include ${MOZILLA_SDK}/mozilla-config.h -I${MOZILLA_SDK}/../include/xpcom -I${MOZILLA_SDK}/../include/nspr -I${MOZILLA_SDK}/../include/embed_base -I${MOZILLA_SDK}/../include/embedstring -I${MOZILLA_SDK}/../include/string" setenv MOZILLA_LIBS "${MOZILLA_SDK}/../lib/libembedstring.a -L${MOZILLA_SDK}/../bin -L${MOZILLA_SDK}/../lib/ -lxpcom -lnspr4 -lplds4 -lplc4" setenv XULRUNNER_INCLUDES "-include ${XULRUNNER_SDK}/include/mozilla-config.h -I${XULRUNNER_SDK}/include" setenv XULRUNNER_LIBS "-L${XULRUNNER_SDK}/lib -lxpcomglue"
Created attachment 129503 [details] another potential patch to build.sh (In reply to comment #16) > When we build swt's libs the following vars are set, maybe these would help? Oh, I was assuming you used build.sh. > setenv XULRUNNER_LIBS "-L${XULRUNNER_SDK}/lib -lxpcomglue" This is where the difference lies. The pkg-config file from xulrunner-devel has -lxpcomglue_s whereas you're using -lxpcomglue.
(In reply to comment #17) > > setenv XULRUNNER_LIBS "-L${XULRUNNER_SDK}/lib -lxpcomglue" > > This is where the difference lies. The pkg-config file from xulrunner-devel > has -lxpcomglue_s whereas you're using -lxpcomglue. I've been in touch with the xulrunner .pc maintainer and the "_s" in there may be incorrect. If that is indeed the case then I'll provide a patch to build.sh to use the pkg-config file but also to rebuild libswt-xpcominit.
Created attachment 131059 [details] build both libswt-xpcominit AND (libswt-xulrunner OR libswt-mozilla)
Created attachment 131060 [details] work around libxul.pc having -lxpcomglue_s and not -lxpcomglue This patch is just to show how I'm currently planning to work around the libxul.pc issue until it's fixed.
FWIW I built 3.4.2 with the second patch (the one to workaround the libxul.pc _s issue) and it worked. I got libswt-xulrunner and libswt-xpcominit and the browser works.
