Community
Participate
Working Groups
1) Sun Solaris 10 SPARC GTK Sun Java 2 Standard Edition 1.4.2_10 for Solaris SPARC is listed as a reference platform here: http://www.eclipse.org/eclipse/development/readme_eclipse_3.2.1.html However, it does not appear on the September 21, 2006 download page: http://download.eclipse.org/eclipse/downloads/drops/R-3.2.1-200609210945/ nor on the 3.3 nightly build http://download.eclipse.org/eclipse/downloads/drops/N20070115-0010/index.php 2) There seems to have been quite a bit of effort in bug #84344 to make Eclipse compile under Solaris 10 for x86. That bug is now marked RESOLVED. How can it makes it way into the official build / reference platform? It does not appear in the DRAFT PLAN for 3.3 (but SPARC does): http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_3.html#TargetOperatingEnvironments
Just like to mention that I know that Solaris 8 is there, just thought that it is inconsistent with the reference platform being Solaris 10.
Sun has been contributed the solaris-gtk-x86 builds to eclipse for 3.2. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=84344#c65 They are the committer on the swt fragment for that port. They contributed a solaris-gtk-x86 build to 3.2 but they didn't contribute a drop yet for 3.2.1. I have asked them in the comment above if they intend to contribute it for 3.2.1. Support for compiling this platform is available in the source build. We don't have the hardware or people resources to provide a download for every possible platform. Therefore, we welcome people who are willing to help out by contributing a fragment, compiling builds as well as bug triage and resolution for a contributed port.
But until someone starts contributing build regularly in sync with what Eclipse is doing, shouldn't Solaris 10 be removed as a reference platform in the Eclipse documentation? How can it be a reference platform if no tests are performed daily? Should it be Solaris 8 in the documentation instead? Reading bug #106784, it seems that only committers can truly create something that is part of the build process. I'm guessing that taking care of a build on Solaris 10 takes a large amount of time that only a big company (such as Sun) can afford without hurting the bottom-line... Am I right?
Our build only runs automated tests on Windows, Mac, and Linux. That being said, all reference platforms listed in the project plan are valid. We have people who run the tests for us on some platforms (for instance linux-gtk-ppc) and report and solve platform specific bugs. Or we have committers who run the tests manually (aix, solaris). If you would like to run the tests locally, you can download the eclipse-Automated-Test-${BuildID}.zip and run the tests on the platform you are interested in. (This zip is located on each build page) Further testing by the community makes eclipse a better product :-)
Closing, if you are interested in contributing a solaris-gtk-x86 build, please let me know.
I'm currently setting up my Solaris 10 environment and testing our software with Eclipse 3.2; I'll give a shot at making a build of Eclipse from source soon. Just wondering if you saw the problem Iain MacDonnell encountered? https://bugs.eclipse.org/bugs/show_bug.cgi?id=84344#c66 Wouldn't it be better to leave this opened with "help needed"?
reopening with helpwanted keyword
At the moment I'm many: "Syntax error, parameterized types are only available if source level is 5.0" even if I used this to build: ./build -os solaris -ws gtk -arch x86 -compilelibs -java5home /usr/jdk/jdk1.5.0_06 I'll attach the steps I've used to set up my environment.
Created attachment 57137 [details] instructions used to try to build Eclipse on Sol 10 x86
Here's a quick note on how I build on Solaris 10 x86 - pretty much the same as Ricky's... http://www.dseven.org/twiki/bin/view/Stuff/EclipseSolaris This works thru 3.2.1, but but 3.3, as already noted.
(In reply to comment #10) > This works thru 3.2.1, but but 3.3, as already noted. Erm, sorry, I guess it wasn't already noted - see Bug #125091
Kim Moir; could bug #125091 be reopened? I've asked over there but no one has answered yet.
Your problems in bug #125091 are really a result of bug 163848
OK, I've been able to squeeze out a 3.3M4 build with this little cheat in build.xml: --- build.xml.orig Mon Jan 22 19:32:07 2007 +++ build.xml Mon Jan 22 19:32:24 2007 @@ -266,6 +266,7 @@ </condition> <property name="bootclasspath" refid="default.bootclasspath" /> <property name="J2SE-1.5" refid="java5.bootclasspath" /> + <property name="JavaSE-1.6" refid="java5.bootclasspath" /> <property name="javadoc1.5" value="${java5.home}/bin/javadoc" /> <!--set the compiler and compiler arguments--> and specifying a path to JSE 6.0 for java5home :) More recent source is more problematic, though...
I have just built Eclipse 3.2.2 from source on Solaris x86 (Developer Express Edition downloaded recently), and from initial testing it appears to work ok. I needed a small patch to include the dt things, and to download java 1.4.2 manually, but except for that it was just a matter of patience. So. 1) Anyone want to try it? 2) Where should I send it as a contributed build for the download page (which incorrectly wants to give me a sparc build)? 3) Who is the swt-maintainer at Sun?
Suresh Raju is the original committer on the swt fragment from sun. I'm not sure if he is still an active committer. In order for it to appear on an eclipse.org download page, you need to be a committer to contribute it. Are you interested in maintaining this fragment? If so, I would post recommend expressing your interest to the swt team.
(In reply to comment #16) > Suresh Raju is the original committer on the swt fragment from sun. I'm not > sure if he is still an active committer. > > In order for it to appear on an eclipse.org download page, you need to be a > committer to contribute it. > > Are you interested in maintaining this fragment? If so, I would post recommend > expressing your interest to the swt team. > I'm interested in helping maintain this fragment. I've got this built with Sun Studio, and am working on adding Mozilla Browser support to the SWT.
re: comment 17 If you get the Browser working on Solaris then please attach a patch to bug 77217.
Hmmm, managed to build 3.3M5eh and everything seems to work so far, but not the editors. The tab appears with the editor title like "Text editor" and than nothing happens - the mouse cursor remains an hour glass forever :( Any hints, what might be wrong (how to trace the problem) ? Here is, what I did so far: http://dev.cs.uni-magdeburg.de/~elkner/eclipse/ Regards, jel.
Are any committers willing to pick up this issue? While I'm sure others would like to help we are constrained by the requirement to be a committer to get a build onto Eclipse.org.
(In reply to comment #20) > Are any committers willing to pick up this issue? > > While I'm sure others would like to help we are constrained by the requirement > to be a committer to get a build onto Eclipse.org. > I've got Eclipse 3.2 to build on Solaris. When I try to get 3.3M6 to build without the --compilelibs argument, I see that the build still tries to build the SWT native code. I've not devoted much time to figuring out why this is so, and just how I should package prebuilt swt browser .so files (Perhaps this weekend). My main interest lies in adding SWT Browser support to Eclipse on Solaris 10 and newer. I've just updated https://bugs.eclipse.org/bugs/show_bug.cgi?id=77217 I'd appreciate any help on figuring out these build issues that I'm facing. Once those are ironed out, I'm willing to contribute builds regularly.
The solaris.gtk.x86 swt fragment is not actively maintained. We had a member of the community that was voted a committer on this fragment but they didn't release the library the compiled to eclipse.org. Thus the source build for solaris.gtk.x86 is configured to recompile these libraries automatically since there aren't any libraries included with the fragment in cvs.
Anyone interested in Solaris x86 support may want to know that there is no native liblocalfile fragment checked in for Solaris x86. This means, that all file system operations are done using java.io.File only, which has the following limitations: * No support for changing read-only status of files from Eclipse * No detection of symbolic links (required for the fix to bug 105554) * Slower than liblocalfile Compiling a native liblocalfile fragment is trivial since the library is really small. For reference, the contribution of liblocalfile for Solaris Sparc is in bug 183137. This contribution contains a BUILD_INFO.txt file with details on which compiler and what command were used to build it for Solaris Sparc. If anybody is interested in contributing a Solaris x86 native fragment for liblocalfile, please open an enhancement request against Platform Resources just like bug 183137. Also, keep an eye on bug 184534 which proposes a better way of registering the native lib with the Java part - when this is fixed, a liblocalfile for a new architecture does not require manual integration to the Java part any more.
Well, since 3.3 is almost final, I took a second try to port 3.3RC4 to solaris.gtk.x86. This time with success. If somebody wanna try it: http://dev.cs.uni-magdeburg.de/lnf/i386/LNFeclipse.tgz or the adjacent http://dev.cs.uni-magdeburg.de/lnf/sparc/LNFeclipse.tgz Both compiled against Solaris Express b55b with JDK 1.6.0_01 and Sun Studio 11. Dueto the lack of proper documentation (what do you consider a fragment, basic idea of the build files aka build flow) I took http://download.eclipse.org/eclipse/downloads/drops/S-3.3RC4-200706081718/download.php?dropFile=eclipse-sourceBuild-srcIncluded-3.3RC4.zip as my base. All patches as well the Build.sh I used are available via http://iws.cs.uni-magdeburg.de/~elkner/eclipse/ . Feel free to integrate the appropriate stuff into the official build scripts etc..
Jens, your Build.sh contains the following two lines: SCRIPTDIR=${SDIR}/../../../etc . ${SCRIPTDIR}/buildfunctions.sh Could you possibly attach a copy of buildfunctions.sh (and whatever other files it depends upon) to this bug report. Also, I keep getting timeouts when trying to download http://dev.cs.uni-magdeburg.de/lnf/i386/LNFeclipse.tgz I really hope someone takes your changes an integrates them into the source build scripts as it is a major pain having no means of building the latest version of Eclipse on solaris-gtk-x86.
Ehhhm, sorry - the firewall restricted access to campus, only. Have changed that, so you should be able to fetch, what you need. Also copied the supporting scripts dir to eclipse/etc so that you are able to see the noise/boilerplate code ;-) BTW: Also had to manipulate the mirrored eclipse/update site to be able to update/install other plugins, because it contains hints to wrong plugin-packages as well :-(. Its still not perfectly clean, but at least working ;-) http://dev.cs.uni-magdeburg.de/eclipse/
Have anyone tried to build 3.3 final using Jens' method?
Eclipse 3.4.1 is available in the OpenSolaris 2008.11 repository (a Reload is needed after installation as it was added very late). Just search for "eclipse" to locate it. It seems to work fine, but you need to add /usr/bin/firefox as an external browser. OpenSolaris 2008.11 does not work with vmware tools yet, but well under VirtualBox.
adding myself to the cc list; surely would like to see solaris/x86 side-by-side with solaris/sparc available as "regular" build...
We don't have the resources to support this build. If you want to build it, please consider building the fragments and recontributing them to eclipse.
Solaris gtk x86 builds have been available since late last week. Please see bug 272211. *** This bug has been marked as a duplicate of bug 272211 ***
