Community
Participate
Working Groups
I wrote in eclipse.platform.swt newsgroup: >>>Hello, >>> >>>I would like to use an eclipse plugin (EchoStudio von NextApp) which use >>>the SWT Browser. But I use a Solaris platform. So you know, I have the "No >>>more handles" exception, because Solaris Motif is not listed as a platform >>>that is supported by the SWT Browser. >>> >>>I am not sure, but if I understand correctly the requierements needed by >>>the SWT browser to support a Motif platform, it should be the existence of >>>Mozilla 1.4 (and GTK2) for this plateform. And today, Mozilla 1.4 exists >>>for Solaris OS. >>>So perhaps, it should be the time to add the Solaris Motif as a platform >>>that is supported by the SWT Browser. What is your point of view? >>>Thank a lot for your anwser. >>>Regards, Stéphane Poltoratzky and Christophe Cornu answered: >>>Hi Stephane, >>> >>>Please open a feature request and paste the information on how you installed >>>the Mozilla 1.4 GTK2 package on that platform. Thanks! >>>Chris So to install Mozilla 1.4 GTK2 in Solaris OS platform, I have followed the instructions given at 'http://wwws.sun.com/software/solaris/browser' link. Please keep me inform about the progress of this feature request. Thanks! Stéphane
*** Bug 77205 has been marked as a duplicate of this bug. ***
Help is wanted on this. Last time we looked at it, we had the feeling that the Unix Mozilla builds are using custom makefiles, unlike the Linux Mozilla build contributed by Mozilla.org, and require very specific gnome/gtk2 builds to be installed. We welcome contributions from people who - know how to get or build the Mozilla 1.4GTK2 SDK on these platforms - build the swt-mozilla-xxxx.so library and run the SWT Browser on these platforms. There could be ABI/C++ compiler issues to work out since our java callback code assumes a particular vtbl organization.
*** Bug 162238 has been marked as a duplicate of this bug. ***
(In reply to comment #2) > Help is wanted on this. > > Last time we looked at it, we had the feeling that the Unix Mozilla builds are > using custom makefiles, unlike the Linux Mozilla build contributed by > Mozilla.org, and require very specific gnome/gtk2 builds to be installed. > I've got Mozilla 1.7.12 to build on Solaris 10 using the Sun Studio compiler. I've also built SWT that's bundled with Eclipse 3.3M6 on Solaris 10 again using the Sun Studio compiler. When I run various SWT Browser snippet code, I get the error that MOZILLA_FIVE_HOME is not set. I've not dug into this owing to lack of time. I've put up instructions on building Mozilla 1.7.12 at http://dynamicproxy.livejournal.com/9478.html Questions: 1. Is it necessary to use older Mozilla code ? Solaris 10 and later come with newer Mozilla code themselves. 2. Is gcc compliance necessary ? Is it OK if I add Sun Studio support too ? 3. Would it be more useful if I investigated XULRunner based support ? 4. Any tips on resolving the MOZILLA_FIVE_HOME problem that I've stated above ?
Thanks for your efforts on this! > 1. Is it necessary to use older Mozilla code ? Solaris 10 and later come with newer Mozilla code themselves. Do you mean older than 1.7.12? Older is usually better since this determines the range of mozilla versions that the browser can be used with (at least back to mozilla 1.4). However I do not think that this is as important on solaris since there is not a legacy of older mozillas that came shipped with solaris 8 and 9 like there was in the linux world. This is not something to worry about for now. > 2. Is gcc compliance necessary ? Is it OK if I add Sun Studio support too ? gcc is not a requirement, swt's libraries on solaris are compiled with a sun compiler that installed in /opt/SUNWspro. Would this be Sun Studio? > 3. Would it be more useful if I investigated XULRunner based support ? This would definitely be nice to have as well. Making this work may not be much different from the mozilla work. > 4. Any tips on resolving the MOZILLA_FIVE_HOME problem that I've stated above ? You should set your MOZILLA_FIVE_HOME and LD_LIBRARY_PATH environment variables to point at your mozilla install (the eclipse launcher usually takes care of this automatically in the linux world). Since you've built mozilla from source this would be the directory where mozilla executable and libraries compiled to; for me this usually ends up in <mozillaDir>/dist/bin.
I see in the steps that the answer for #2 is "yes, they're the same".
If you need any more detail on the compiler (and hardware) that the swt libraries are compiled with (on), I just happen to have that info from another discussion <g>: Solaris version: 5.10 Machine hardware: sun4u OS version: 5.10 Processor type: sparc Hardware: SUNW,Sun-Blade-100 /opt/SUNWspro/bin/cc: Sun C 5.5 2003/03/12
(In reply to comment #5) > Thanks for your efforts on this! > :) > > 1. Is it necessary to use older Mozilla code ? Solaris 10 and later come with > newer Mozilla code themselves. > > Do you mean older than 1.7.12? Older is usually better since this determines > the range of mozilla versions that the browser can be used with (at least back > to mozilla 1.4). However I do not think that this is as important on solaris > since there is not a legacy of older mozillas that came shipped with solaris 8 > and 9 like there was in the linux world. This is not something to worry about > for now. > Ack. I shall continue with Mozilla 1.7.12 for now. > > 2. Is gcc compliance necessary ? Is it OK if I add Sun Studio support too ? > > gcc is not a requirement, swt's libraries on solaris are compiled with a sun > compiler that installed in /opt/SUNWspro. Would this be Sun Studio? > That is gcc by default. Some some (now unjustifiable) reasons, I was determined to get everything to build with Sun Studio. After hitting some roadblocks on a flight yesterday with trying to get the SWT to build, I'm now much chastened and shall try to build Mozilla and SWT with the gcc tonight. > > 3. Would it be more useful if I investigated XULRunner based support ? > > This would definitely be nice to have as well. Making this work may not be > much different from the mozilla work. > Ack. Any pointers on how I make Eclipse point to an external XULRunner instance ? > > 4. Any tips on resolving the MOZILLA_FIVE_HOME problem that I've stated above ? > > You should set your MOZILLA_FIVE_HOME and LD_LIBRARY_PATH environment variables > to point at your mozilla install (the eclipse launcher usually takes care of > this automatically in the linux world). Since you've built mozilla from source > this would be the directory where mozilla executable and libraries compiled to; > for me this usually ends up in <mozillaDir>/dist/bin. > I did this on the flight last evening. I'll attach the error log that I get when I run the SWT Browser snippet.
Created attachment 64892 [details] XPCOM VTable error when trying to get the SWT Browser to run Here's the error I get when I try to get the SWT Browser to run. - Eclipse 3.2 - SWT built with Sun Studio 11 - Mozilla 1.7.12 built with Sun Studio 11 - MOZILLA_FIVE_HOME points to mozilla/dist/bin The code snippet is the SWT Browser snippet number 128 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet128.java?view=co
(In reply to comment #7) > If you need any more detail on the compiler (and hardware) that the swt > libraries are compiled with (on), I just happen to have that info from another > discussion <g>: > > Solaris version: 5.10 > Machine hardware: sun4u > OS version: 5.10 > Processor type: sparc > Hardware: SUNW,Sun-Blade-100 > > /opt/SUNWspro/bin/cc: Sun C 5.5 2003/03/12 > Thanks. Now I'm wondering if I'd packaged my swt binaries correctly. I've posted an attachment to this bug where I see that there are some vtable issues. I think this is because there are different compilers that I'm using. I'll try with the gcc keep this bug list updated.
> Any pointers on how I make Eclipse point to an external XULRunner instance? Since you're on eclipse 3.2 you should do the same as for mozilla (set MOZILLA_FIVE_HOME and LD_LIBRARY_PATH). There is a better xulrunner-specific lookup mechanism used in 3.3. > I'll attach the error log that I get when I run the SWT Browser snippet. This definitely could be a case of a compiler incompatibility.
This probably won't help you at all, particularly if we are talking about compiler incompatibility issues, but from the "for what it's worth" department, here's the entire compile-and-link console output for a typical build of the swt libraries: cc -O -DSWT_VERSION=3336 -DSOLARIS -DGTK -DCDE -I/usr/j2se/include -I/usr/j2se/include/solaris -K PIC -I/usr/dt/include -c swt.c cc -O -DSWT_VERSION=3336 -DSOLARIS -DGTK -DCDE -I/usr/j2se/include -I/usr/j2se/include/solaris -K PIC -I/usr/dt/include -c c.c cc -O -DSWT_VERSION=3336 -DSOLARIS -DGTK -DCDE -I/usr/j2se/include -I/usr/j2se/include/solaris -K PIC -I/usr/dt/include -c c_stats.c cc -O -DSWT_VERSION=3336 -DSOLARIS -DGTK -DCDE -I/usr/j2se/include -I/usr/j2se/include/solaris -K PIC -I/usr/dt/include -c callback.c cc -G -K PIC -s -o libswt-gtk-3336.so swt.o c.o c_stats.o callback.o cc -O -DSWT_VERSION=3336 -DSOLARIS -DGTK -DCDE -I/usr/j2se/include -I/usr/j2se/include/solaris -K PIC -I/usr/dt/include `pkg-config --cflags gtk+-2.0` -c os.c cc -O -DSWT_VERSION=3336 -DSOLARIS -DGTK -DCDE -I/usr/j2se/include -I/usr/j2se/include/solaris -K PIC -I/usr/dt/include `pkg-config --cflags gtk+-2.0` -c os_structs.c cc -O -DSWT_VERSION=3336 -DSOLARIS -DGTK -DCDE -I/usr/j2se/include -I/usr/j2se/include/solaris -K PIC -I/usr/dt/include `pkg-config --cflags gtk+-2.0` -c os_custom.c cc -O -DSWT_VERSION=3336 -DSOLARIS -DGTK -DCDE -I/usr/j2se/include -I/usr/j2se/include/solaris -K PIC -I/usr/dt/include `pkg-config --cflags gtk+-2.0` -c os_stats.c cc -G -K PIC -s `pkg-config --libs-only-L gtk+-2.0 gthread-2.0` -lgtk-x11-2.0 -lgthread-2.0 -L/usr/openwin/lib -Wl,-R -Wl,/usr/openwin/lib -lXtst -o libswt-pi-gtk-3336.so swt.o os.o os_structs.o os_custom.o os_stats.o cc -O -DSWT_VERSION=3336 -DSOLARIS -DGTK -DCDE -I/usr/j2se/include -I/usr/j2se/include/solaris -K PIC -I/usr/dt/include `pkg-config --cflags atk gtk+-2.0` -c atk.c cc -O -DSWT_VERSION=3336 -DSOLARIS -DGTK -DCDE -I/usr/j2se/include -I/usr/j2se/include/solaris -K PIC -I/usr/dt/include `pkg-config --cflags atk gtk+-2.0` -c atk_structs.c cc -O -DSWT_VERSION=3336 -DSOLARIS -DGTK -DCDE -I/usr/j2se/include -I/usr/j2se/include/solaris -K PIC -I/usr/dt/include `pkg-config --cflags atk gtk+-2.0` -c atk_custom.c cc -O -DSWT_VERSION=3336 -DSOLARIS -DGTK -DCDE -I/usr/j2se/include -I/usr/j2se/include/solaris -K PIC -I/usr/dt/include `pkg-config --cflags atk gtk+-2.0` -c atk_stats.c cc -G -K PIC -s `pkg-config --libs-only-L atk gtk+-2.0` -latk-1.0 -lgtk-x11-2.0 -o libswt-atk-gtk-3336.so swt.o atk.o atk_structs.o atk_custom.o atk_stats.o cc -O -DSWT_VERSION=3336 -DSOLARIS -DGTK -DCDE -I/usr/j2se/include -I/usr/j2se/include/solaris -K PIC -I/usr/dt/include -c swt_awt.c cc -L/usr/j2se/jre/lib/sparc -ljawt -G -s -o libswt-awt-gtk-3336.so swt_awt.o cc -O -DSWT_VERSION=3336 -DSOLARIS -DGTK -DCDE -I/usr/j2se/include -I/usr/j2se/include/solaris -K PIC -I/usr/dt/include -c cde.c cc -O -DSWT_VERSION=3336 -DSOLARIS -DGTK -DCDE -I/usr/j2se/include -I/usr/j2se/include/solaris -K PIC -I/usr/dt/include -c cde_structs.c cc -O -DSWT_VERSION=3336 -DSOLARIS -DGTK -DCDE -I/usr/j2se/include -I/usr/j2se/include/solaris -K PIC -I/usr/dt/include -c cde_stats.c cc -G -K PIC -s -L/usr/dt/lib -R/usr/dt/lib -lXt -lX11 -lDtSvc -o libswt-cde-gtk-3336.so swt.o cde.o cde_structs.o cde_stats.o
Duh.. I'd not added myself to the CC list. I'm in SFO for the Javaone event (I'm presenting on OpenGrok on Monday) and hope to work on the bug during this week.
Sriram, I wonder if you have any updates on swt browser in Solaris. thanks for your work!
Sriram, It's a long time since you posted here last time. Will you take care about this bug? If not, could you please provide us with your latest findings?
(In reply to comment #15) > Sriram, > It's a long time since you posted here last time. > Will you take care about this bug? > If not, could you please provide us with your latest findings? My apologies. I've just rolled off a very intensive project, and am on a brief vacation. I'll post my findings as well as the build scripts etc once I get back to work (the code's on my Solaris x86 box at work). Meanwhile, here's the status: 1. Compiled Firefox 2.0.0.6 using Sun Studio. 2. Compiled SWT using Sun Studio. 3. Was struggling with placing the binaries in the right location. 4. Was struggling with using patches for the Solaris build. I should be back at work on Monday (IST - +5:30 GMT), and will post my script modifications, etc then. -- Sriram
I'am following this bug and your previous discussion on SWT newsgroup to achieve SWT+Browser, but for Sparc arch. Unfortunately currently I have only x86 and wonder if there are any common issues that I can expect later on sparc.
My apologies again. I've changed my job profile and am now a trainee network admin - the past five weeks have been very hectic. I tried to build Firefox again this weekend on my new laptop on SXCE build 66 (with Xen patches), and I'm facing problems with "libnspr4.a not found". I'd solved this earlier, but have forgotten how I'd done that. Does anyone have any clue on how this problem can be solved ? I've followed my own instructions posted at my journal: http://dynamicproxy.livejournal.com/14542.html
(In reply to comment #18) > I tried to build Firefox again this weekend on my new laptop on SXCE build 66 > (with Xen patches), and I'm facing problems with "libnspr4.a not found". I'd > solved this earlier, but have forgotten how I'd done that. Sriram, I belive I had the same problem, but didn't solved it. Currently I'm working on Sparc, but didn't get to mozilla yet - I hope to compile it this week.
Hi, I can't wait for this feature to work on Solaris, and I'd like to look into the issue myself; maybe I can assist with this a little. This may be a stupid question, but where in Eclipse's CVS repository can I find the following items: - the platform-specific Java code for SWT on Solaris/GTK - the native C code for SWT on Solaris/GTK - the platform-specific Java code for SWT on Linux/GTK (for reference) - the native C code for SWT on Linux/GTK (for reference) I guess I've probably been looking in the wrong spots; so far I could only find some precompiled .so files but no sources. Thanks, Mirko
The best way to get all of this is from CVS as described in http://www.eclipse.org/swt/cvs.php. You'll find the .c/.h files in <projectDir>/bin/library. In case you're wondering the following env. variables are set when running this locally on linux: setenv MOZILLA_SDK /bluebird/teamswt/swt-builddir/mozilla/1.4/linux_gtk2/mozilla/dist/sdk 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_SDK /bluebird/teamswt/swt-builddir/geckoSDK/1.8.0.4/gecko-sdk setenv XULRUNNER_INCLUDES "-include ${XULRUNNER_SDK}/include/mozilla-config.h -I${XULRUNNER_SDK}/include" setenv XULRUNNER_LIBS "-L${XULRUNNER_SDK}/lib -lxpcomglue" As a side note, we have a theory that there's an ABI incompatibility on Sparc similar to Itanium (see bug 123949). If this is the case then the current approach of using vtbl calls may either need to be modified on Sparc or thrown out altogether and replaced with direct function calls.
Thanks for the response, Grant. There must be some misunderstanding here; you mentioned <projectDir>/bin/library as the location for the C sources, but I don't see any bin/library folders in http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.swt.gtk.linux.x86/ - only .so files that were checked in earlier this week. Could it be that something was moved just recently? Can you send me a ViewCVS link to the native C code?
All of the source for SWT - Java, C, etc. - can be found in the org.eclipse.swt project. The C source files are found in the various "PI" (Platform Interface) library directories. For example, the GTK C source is in /org.eclipse.swt/Eclipse SWT PI/gtk/library So the ViewCVS link for this would be: http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.swt/Eclipse SWT PI/gtk/library Hope this helps.
Once the source has been retrieved into your workspace and built as described in the link from comment 21, the various *.c/*.h files end up together in your org.eclipse.swt/bin/library directory, where they can be compiled with build.sh.
(In reply to comment #18) > I tried to build Firefox again this weekend on my new laptop on SXCE build 66 > (with Xen patches), and I'm facing problems with "libnspr4.a not found". I'd > solved this earlier, but have forgotten how I'd done that. for me it turned out that ar was not on the path. ln -s /usr/ccs/bin/ar /usr/bin/ar Sriram, Marco: anyone of you had any further progress?
> Sriram, Marco: anyone of you had any further progress? sorry, I meant Mirko...
Jacek, unfortunately I didn't have much time to tinker around with this. I finally checked out all the relevant sources and had a quick look at the code, but I didn't set up the build yet. Probably there will not be much news from me in the upcoming weeks, either...
(In reply to comment #25) > (In reply to comment #18) > > I tried to build Firefox again this weekend on my new laptop on SXCE build 66 > > (with Xen patches), and I'm facing problems with "libnspr4.a not found". I'd > > solved this earlier, but have forgotten how I'd done that. > > for me it turned out that ar was not on the path. > ln -s /usr/ccs/bin/ar /usr/bin/ar > > Sriram, Marco: anyone of you had any further progress? > My apologies for the delay and the radio silence, folks, but a career move involved much learning and adventures. Ever since I moved to infrastructure work, I've made little time :( I have some updates, though: - I was able to build FF 2.0.0.7 on SXCEb68, and this works just fine. - My eclipse source download was screwed up, and I missed out on some files. - When I checked out 3.4m3, I discovered that it wouldn't build. Kim Moir checked in a fix for that, but I've not built again. I think this weekend would be a good time. I've also proposed a talk at EclipseCon on Embedding Mozilla, and I've set myself a target of getting a port to Solaris ready by November end.
Thanks, so I guess it's my turn now :) 1. I have compiled Mozilla 1.7.12 with following options: ac_add_options --enable-xft ac_add_options --disable-freetype2 ac_add_options --disable-tests ac_add_options --enable-debug ac_add_options --disable-svg ac_add_options --disable-canvas ac_add_options --enable-optimize ac_add_options --disable-auto-deps ac_add_options --enable-default-toolkit=gtk2 (it was inspired by Sriram's stuff. I only had to make sure that -enable-optimize is set, because in other way I got compiler crash (!) ) 2. Compiled SWT to link against Mozilla. I used make -f make_solaris.mak make_mozilla My modifications to make_solaris.mak: -change the include paths to Mozilla. My Mozilla had a bit different directory structure. - remove some options that compiler complained it doesn't know, eg. -W* - I didn't add anything extra 3. Run a sample java SWT browser app. It crashes at some stage of Mozilla init. (It may be caused by improper Mozilla setup, as there is a system default Mozilla and my one, I did't have time to investigate it yet) My env is: SWT from CVS tagged R3_2, Solaris 10, Arch: x86, Sun Studio 12, Mozilla 1.7.12
Created attachment 83318 [details] mozilla init crash log So this is what i get calling "new Browser(shell, SWT.NONE);" Also stdout is flooded by Mozilla init output: [...lot of successful initialization msgs...] *** Registering nsMsgMailViewModule components (all right -- a generic module!) *** Registering nsBayesianFilterModule components (all right -- a generic module!) nsNativeComponentLoader: autoregistering succeeded JS Component Loader: ERROR# # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0xd2ad4c8c, pid=1055, tid=1 # # Java VM: Java HotSpot(TM) Client VM (1.5.0_07-b03 mixed mode, sharing) # Problematic frame: # C [libc.so.1+0x24c8c] strlen+0xc # # An error report file with more information is saved as hs_err_pid1055.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # No Persistent Registry Found. Type Manifest File: /export/home/mozz/mozilla/dist/bin/components/xpti.dat
(In reply to comment #30) > Created an attachment (id=83318) [details] > mozilla init crash log ok, that was the Mozilla configuration issue. After installing Mozilla and setting correct MOZILLA_FIVE_HOME (in my case it's /usr/local/lib/mozilla-1.7.12) I get exactly the same stack as in Sriram's attachement 1.
Some progress. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=84344 I have to try and recover my hard disk contents tomorrow, else spend some time again this weekend on a new laptop.
*** Bug 266547 has been marked as a duplicate of this bug. ***
Any news on building xulrunner on Solaris? - According to bug 262929 comment 12, xulrunner 1.9.0.8 seems to be the version of choice these days. Has anybody succeeded building it on Solaris yet? Also, be aware that this CQ: https://dev.eclipse.org/ipzilla/show_bug.cgi?id=1528 seems to be relatively close to approving xulrunner in terms of IP clearance for bundling with Eclipse by means of putting it into Orbit... so having xulrunner on all Eclipse Platforms gets even more interesting!
Any update, anyone? - I searched the Internet a little but only found Firefox 2.0.0.17 from blastwave and Firefox 3.0.5 from mozilla contrib (might have some issues), but no xulrunner binary anywhere yet...
I'm looking at this with Bogdan now, and have been able to get the Browser working on Solaris-x86 using the firefox that ships with OpenSolaris. We're beginning to look into whether a similar approach will work on Solaris Sparc. I haven't found a downloadable xulrunner binary for Solaris either. Downloadable firefoxes are likely to not be usable by the Browser because they're usually statically linked.
Created attachment 132756 [details] Output of find /usr/sfw/lib/mozilla -name "*.so" Not sure if it helps, but on our Solaris 10 Sparc box we've got "Mozilla 1.7 for Sun Java Desktop System" installed in /usr/sfw/lib/mozilla -- and it's dynamically linked, see attached directory listing. Would such an old version be usable as browser widget? The latest firefox 3.0.9 from the Solaris 10 SPARC "contributed" build also seems to be dynamically linked: http://releases.mozilla.org/pub/mozilla.org/firefox/releases/3.0.9/contrib/ -rwxr-xr-x mozilla/other 48543792 2009-04-17 19:34:18 firefox/libxul.so Here is some background info on the Solaris 10 contributed builds. It looks like dependent dynamic libs are included, so it should be possible to run xulrunner out of these packages: http://blogs.sun.com/pengyang/entry/enjoy_firefox_3_0_on http://blogs.sun.com/pengyang/entry/q_a_the_firefox_3 http://blogs.sun.com/pengyang/entry/update_firefox_3_0_contributed http://blogs.sun.com/pengyang/entry/firefox_3_0_3_builds I haven't found anything for Solaris 9 though...
Browser support is now released for Solaris on x86. There are changes required from two other components to make the experience seemless in eclipse: - bug 273603 : update launcher to set browser env. vars. on Solaris - bug 273616 : show "correct" intro page on Solaris-x86 [not really critical] Note that our Solaris x86 dev machine here is running OpenSolaris, so if someone with a Solaris 10 x86 install could take it for a spin it would be appreciated. I believe that the launcher bug listed above will be fixed imminently, so any eclipse builds that run this weekend will hopefully have Browser support ready to go (just possibly with the wrong intro screen). Browser support on sparc is still being investigated. re: comment 37 I found a post today indicating that the solaris compiler will not do static linking the way mozilla.org likes to when compiling firefox on other platforms. I've confirmed that the contributed solaris builds on mozilla.org are dynamically linked, and the Browser was able to use one of them.
according to new and noteworthy* browser widget is supported on solaris since 3.5M7. I think this bug may be marked as fixed. new and noteworthy (http://download.eclipse.org/eclipse/downloads/drops/S-3.5M7-200904302300/eclipse-news-M7.html)
This bug is still open for the Solaris SPARC case.
Created attachment 136075 [details] patch that adds Browser support on SPARC The attached patch gets the Browser working on Solaris SPARC. It will not be in eclipse/swt 3.5, but should be released to the 3.6 stream once 3.5 is complete, and will be considered for 3.5.1 if it proves to be stable in the interim. The only SPARC box here is running Solaris 10, so it would be helpful to know how well it runs on other Solaris versions. Anyone wishing to take it for a spin should do the following: - retrieve the org.eclipse.swt and org.eclipse.swt.gtk.solaris.sparc projects from cvs and build swt for gtk (steps: http://www.eclipse.org/swt/cvs.php ) - in the resulting .classpath file change the value of org.eclipse.jdt.launching.CLASSPATH_ATTR_LIBRARY_PATH_ENTRY to org.eclipse.swt.gtk.solaris.sparc - apply the attached patch, it will modify both of these projects - drop the swt library that will be in the next attachment into the org.eclipse.swt.gtk.solaris.sparc project, and if the version number in its name does not match the other libs in the project then rename it to match - run something like http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet128.java?view=co but be sure to first set the MOZILLA_FIVE_HOME and LD_LIBRARY_PATH environment variables in the launch configuration (on Solaris 10 these should be /usr/sfw/lib/mozilla/)
Created attachment 136076 [details] swt mozilla library for sparc
Created attachment 137061 [details] improved patch that adds Browser support on SPARC
The fix for Solaris-GTK on SPARC has been released to the 3.6 stream. If it proves to be stable over the next while then it will likely be added to the 3.5.1 stream as well. The fix for Solaris-Motif has not been released because it introduced instability. For those that are keen for this functionality, please download a 3.6-stream integration build when it becomes available (the first one should happen on June 30th) and if there are problems then follow up here. Thanks!
I have just run into this with a version of 3.4.2 we are using on open solaris (x86) and have a few questions: - Is it possible for me to make that work (programmatically from our plugin)? - Can you point me at a JavaEE IDE 3.5 download for solaris x86 so I can see if it works for me there? The notes here seem to indicate that it should be, but I cannot find a download to use.
re: comment 45 You won't be able to enable this from your plug-in, the changes to the swt plug-in itself are required. If you want to do an experiment with this: -> retrieve version R3_5 of the org.eclipse.swt and org.eclipse.swt.gtk.solaris.x86 projects from dev.eclipse.org, and rename .classpath_gtk to .classpath (steps: http://www.eclipse.org/swt/cvs.php ) -> self-host (Run > Run As > Eclipse Application) with a launch configuration that sets the MOZILLA_FIVE_HOME and LD_LIBRARY_PATH environment variables to an available browser to embed (eg.- I think /usr/lib/firefox is fine) -> note that the Welcome page will not attempt to use the Browser in 3.4.2 because it does a platform check (see bug 273616) Regarding 3.5, I don't see a Solaris x86 download on http://www.eclipse.org/downloads/packages/eclipse-ide-java-ee-developers/galileor , but perhaps you could just get the regular eclipse SDK release at http://download.eclipse.org/eclipse/downloads/drops/R-3.5-200906111540/index.php and use the Update Manager (Help > Install New Software...) to install the Java EE parts? I notice that category "Web, XML and Java EE Development" has item "Eclipse Java EE Developer Tools".
To update, I notice that this is not working in the 3.6 stream builds, but is working in them when self-hosting. Presumably it's a library loading problem of some sort, which needs to be investigated.
Created attachment 143267 [details] hs_err of JVM crash when self-hosting with I20090729-1307 (In reply to comment #37) I just tried again on Solaris SPARC, with eclipse-SDK-I20090729-1307 (3.6 Stream build) and firefox-3.0.9 as per comment 37. No browser, even when setting various selections of LD_LIBRARY_PATH, MOZILLA_FIVE_HOME, -Dorg.eclipse.swt.browser.XULRunnerPath and the like... So I tried self-hosting (Run Configurations... New Eclipse... Run) but got a JVM Crash as attached: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0xd7563518, pid=24707, tid=1 # # Java VM: Java HotSpot(TM) Server VM (1.5.0_06-b05 mixed mode) # Problematic frame: # C [libxul.so+0x1563518] __1cYnsNativeCharsetConverterPUnicodeToNative6MppkHpIppc4_I_+0x2e0 # # An error report file with more information is saved as hs_err_pid24707.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # Grant, are you going to do the investigations mentioned in comment 47? Is there any way I can help?
Again, how can I help bringing this forward? I can try debugging this on our Solaris box, but any hints regarding what I should watch out for would be helpful.
Sorry for the late response, I was a way for two weeks, and will revisit this first thing tomorrow. I previously had a chance to investigate comment 47 though, and found that the Crun library (C++ runtime) needs to be loaded. This should not be a major fix to make. However your crash is more worrying, so I'll try the firefox that you specified tommorrow. Questions in the meantime: - you presumably set MOZILLA_FIVE_HOME to help this firefox be found, did you set LD_LIBRARY_PATH to the same value as well? - which solaris version did you see this on? - does self-hosting work better for you if you set MOZILLA_FIVE_HOME and LD_LIBRARY_PATH to the OS's shipped browser instead (on Solaris 10 this is in /usr/sfw/lib/mozilla)?
(In reply to comment #50) > - you presumably set MOZILLA_FIVE_HOME to help this firefox be found, did you > set LD_LIBRARY_PATH to the same value as well? I tried several combinations, but I'm pretty sure that the one with LD_LIBRARY_PATH == MOZILLA_FIVE_HOME was one of them. At the time it crashed, I had proably also added firefox/depend/lib which contains several replacement versions of GTK libs. > - which solaris version did you see this on? 136 mober@szg-tf-pb01s~/firefox-solaris>uname -a SunOS szg-tf-pb01s 5.10 Generic_137111-07 sun4u sparc SUNW,Sun-Fire-V210 > - does self-hosting work better for you if you set MOZILLA_FIVE_HOME and > LD_LIBRARY_PATH to the OS's shipped browser instead (on Solaris 10 this is in > /usr/sfw/lib/mozilla)? Indeed, this works! setenv MOZILLA_FIVE_HOME /usr/sfw/lib/mozilla setenv LD_LIBRARY_PATH ${MOZILLA_FIVE_HOME}:/usr/local/lib setenv PATH ${MOZILLA_FIVE_HOME}:${PATH} eclipse Allows me to self-host with browser, although the hosting Eclipse does not have a browser. Interestingly, while the xulrunner works, if I launch /usr/sfw/lib/mozilla/mozilla & directly, I get a message about converting a netscape 4 profile but then nothing happens.
PS Setting the very same variables to my firefox-3.0.9 reproduces exactly the crash from Comment #48 .
Created attachment 145171 [details] 3.5.1 patch for SPARC
The C++ runtime library is now explicitly loaded on SPARC, so the Browser now works in non-self-hosted contexts in 3.6. Browser support has also been added in the 3.5.1 stream. Environment variables like MOZILLA_FIVE_HOME and LD_LIBRARY_PATH should not need to be set because the eclipse launcher takes care of this. Note that the minimal required Solaris version for this is Solaris 10. Behaviour on earlier Solaris versions has not changed. Fixed in the 3.5.1 and 3.6 streams > 20090820
(In reply to comment #41) > The only SPARC box here is running Solaris 10, so it would be helpful to know > how well it runs on other Solaris versions. Anyone wishing to take it for a > spin should do the following: Although the latest comments seemed to indicate that this is deliberately intended to work on Solaris 10 only, I thought I'd give it a shot on Solaris 9 -- with an old Mozilla installation of mine. Here is what I did, with yesterday's M20090824-0800 build: setenv MOZILLA_FIVE_HOME /Tools/mozilla/1.7.3/SunOS/5.8 setenv LD_LIBRARY_PATH ${MOZILLA_FIVE_HOME}:${LD_LIBRARY_PATH} ./eclipse -vmargs -Dorg.eclipse.swt.browser.XULRunnerPath=${MOZILLA_FIVE_HOME} Browser did not come up, but the external web browser was usable. Is there any sense in continuing to check this on Solaris 9? Or is there just no chance it could ever work?
It may be usable on Solaris 9 if the dependencies are resolvable there, but I'm not sure that this is the case. Can you try the following: - unzip an swt jar that has the fix - set the LD_LIBRARY_PATH environment variable to an available mozilla (directory should contain libxpcom.so, libnspr4.so, etc.) - ldd libswt-mozilla-gtk-XXXX.so, do the dependencies all resolve? If so... - do your steps from comment 55 but DON'T specify the -Dorg.ecl...XULRunnerPath switch Also, do you know which directory the browser that ships with Solaris 9 lives in? It's not called mozilla, but I think it's mozilla-based (?).
ldd does not report any missing dependencies on my box. Setting LD_LIBRARY_PATH and MOZILLA_FIVE_HOME but no -Dorg.eclipse.swt.browser.* does not produce an internal webbrowser, also not if self-hosting. FYI, when I launch Eclipse it reports a WARNING that my GTK+ is too old (2.2.0 required, 2.1.0 found). Fonts are not perfect (lots of "WARNING **: couldn't load font...") , but it still runs. I don't even know whether a webbrowser ships with Solaris 9 by default, so I'm afraid I cannot help here. I've been testing with a version that "somebody" installed a long while back. Should I go and debug anything?
Since the browser is failing to appear on Solaris 9 but is not crashing there must be a controlled problem happening at creation time. If you want to see where it's failing it should just require the following: - retrieve swt from cvs: http://www.eclipse.org/swt/cvs.php (additional step: after renaming .classpath_gtk to .classpath, change its CLASSPATH_ATTR_LIBRARY_PATH_ENTRY value to org.eclipse.swt.gtk.solaris.sparc ) - put a breakpoint in Mozilla.create() - run http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet128.java Marking bug as VERIFIED since it worked in yesterday's 3.5.1 build on Solaris 10.
Created attachment 146000 [details] hs_err of JVM crash with firefox-3.0.9 With M20090824-0800 I can verify that the browser in /usr/lib/sfw/mozilla works fine now. My downloaded firefox-3.0.9, however, still crashes with attached hs_err_pid21168.log (when setting MOZILLA_FIVE_HOME and LD_LIBRARY_PATH, then starting eclipse and choosing Help > Welcome). On my Solaris 9 with mozilla 1.7.3, it looks like it fails at rc = componentManager.CreateInstance(XPCOM.NS_APPSHELL_CID, 0, ... because after the call, rc == -2147221164 == 0x80040154 which neither matches XPCOM.NS_ERROR_NO_INTERFACE nor XPCOM.NS_OK, but seems to be NS_ERROR_FACTORY_NOT_REGISTERED does that help? Since the standard mozilla now works, should the remaining discussions for ff3.0.9 and solaris9 be put into separate new bugs?
Created attachment 146001 [details] hs_err of JVM crash with firefox-3.5.2 On Solaris 10, with a downloaded Firefox 2.0.0.20 from here: http://releases.mozilla.org/pub/mozilla.org/firefox/releases/2.0.0.20/contrib/solaris_tarball/firefox-2.0.0.20.en-US.solaris8-sparc-gtk1.tar.bz2 I see exactly the same behavior as on Solaris 9 -- it fails with NS_ERROR_FACTORY_NOT_REGISTERED on componentManager.CreateInstance(XPCOM.NS_APPSHELL_CID With a downloaded Firefox 3.5.2 from here: http://releases.mozilla.org/pub/mozilla.org/firefox/releases/3.5.2/contrib/solaris_tarball/firefox-3.5.2.en-US.solaris-10-fcs-sparc.tar.bz2 I'm getting attached JVM crash.
I've logged bug 288361 for the crashes in non-default native browsers on SPARC. The default browser that ships on Solaris 10 seems adequate for all basic Browser functionality, there shouldn't be a need to override it to use a different one.
FYI, I just noticed that since this bug is fixed, the SWT FAQ needs updating: http://www.eclipse.org/swt/faq.php#browsersolaris
Thanks for pointing this out! I've updated the text.
