How to build Eclipse for Solaris x86These are the instructions for building Eclipse on Solaris x86 svn90 and above. This is a baseline build where we start with a fresh Solaris installation and only use the packages available from the Open Solaris repository. Sun Studio Express is used as the C compiler. Limitations:- The build has not been tested with 64 bit Java although Eclipse will run with a 64 bit JVM.
- There is no OpenGL support.
- There is no xulrunner support. (Workaround: To view help you can set your external browser.)
Prerequisites:- The following pacakges should be installed from the Open Solaris repository:
- sunstudioexpress
- SUNWant
- SUNWgnome-common-devel
- SUNWxwinc
- SUNWxorg-headers
- The following JDK's are also needed (self extracting is fine):
Process:- Download the Source Build for Eclipse.
- Create a directory (referred from now on as BUILD_DIR).
- Unzip the eclipse-sourceBuild-srcIncluded-3.4.2.zip in the BUILD_DIR.
- Replace the build.xml in the BUILD_DIR with the one provided in the source scripts area.
- Download and save the solipse_build.sh (located in the source area) into the BUILD_DIR.
- Modify the following path values in the the solipse_build.sh: JAVA_HOME, J2SE15 and J2SE14 to the path of your JDK 6, JDK 5 and JDK 1.4 respectively.
- Make the build script executable (e.g. '$ chmod 700 solipse_build.sh').
- Run the build script (e.g. '$ ./solipse_build.sh')
- It takes about 20 minutes or more to build.
- You should have two unpacked installations in your build directory: eclipse and eclipse-provisioned. eclipse-provisioned has been p2-enabled; the other requires that you enable the legacy update manager.
Recent Changes:The build scripts have been moved out of the downloads area and into the source/trunk/scripts area. This will allow script content to change without changes to the file names. It will also allow version tracking. This happened because of the last few changes to the solipse_build.sh script -- for each change, a new script was uploaded with a new name per Google Code's restrictions. The scripts in the download area have since been deprecated. The Solipse build script has been tested on Eclipse 3.4.2.
|
Sign in to add a comment
Great stuff, many thanks!
What ends up needing to be packaged? BUILD_DIR/eclipse looks to be most of it, though I noticed that the eclipse executable was loading in stuff like:
~/.eclipse/org.eclipse.platform_3.4.0_1473617060/configuration/org.eclipse.osgi/bundles/292/1/.cp/libswt-atk-gtk-3448.so
These don't seem to be present in BUILD_DIR/eclipse.
Awesome and great work, thanks guys ! now testing the functionality of the eclipse. succeed here in OpenSolaris 2008.05?
well seems everything is ok and working good except the update manager, i'm also not able to install the PDT .. any idea ? thanks
I found how to turn on old Update Manager and use it in OS 2008.05. Here it is an instruction http://wiki.eclipse.org/Equinox_p2_Removal
I think it is a good candidates for appending into build script.
It doesn't want to work here, here is what I did so far :
- replaced the eclipse.ini with the older version 3.3.2? - removed everything in "configuration" except "config.ini" - removed the "org.eclipse.equinox.p2.user.ui." from "features" - remvoed the "p2" folder - nothing found in plugins, and the "dropins" folder is not here too. what can i do further to remove th p2 ?
I noticed that everytime I open it, it restore evrything again and all folders and everything ??
In plugins folder you should found folders like .p2. and remove them.
Folders and files.
The p2 update manager can be disabled and the legacy update manager can be enabled simply by going to Window -> Preferences -> General -> Capabilities and selecting the old update manager option, so there is no need to roll this into the build script. I have been able to generate the p2 SDKProfile tonight thanks to a comment in my blog entry (http://timezra.blogspot.com/2008/06/solipse-for-building-eclipse-on-solaris.html). I will roll p2 provisioning into the build script as soon as I have tested it's behavior as part of the entire build process. -----Tim------
Building with solipse_build_with_p2.sh worked last night, and I have successfully been able to use the p2 update manager. solipse_build.sh has been deprecated. Unfortunately, I could not just replace the contents of the solipse_build.sh script because the file is a part of the project history (thanks for all the downloads!). If you do use solipse_build_with_p2.sh, just make sure to use the "eclipse-provisioned" distribution in the build directory and not the "eclipse" distribution. -------Tim-------
I use a standard Solaris 10 system and after downloading the Solipse build script, I had to modify it to account for the fact that "-shared" is not a valid flag for cc - it should be "-G" instead. I'm not sure what the best way to submit this patch is so here's the output of diff:
227c227 < perl -pi -e 's~gcc\s-o\s\$\{library-file\}\s-shared\s-I\$\{src-path\}\s-I\$\{header-solaris-path\}\s-fPIC\s\$\{library-file\}~$ENV{SUN_STUDIO_HOME}/bin/cc -o \$\{library-file\} -G -I\$\{src-path\} -I\$\{header-path\} -I\$\{header-solaris-path\} -KPIC \$\{src-path\}/.c~' ./plugins/org.eclipse.update.core.solaris/src/build.xml --- > perl -pi -e 's~gcc\s-o\s\$\{library-file\}\s-shared\s-I\$\{src-path\}\s-I\$\{header-solaris-path\}\s-fPIC\s\$\{library-file\}~$ENV{SUN_STUDIO_HOME}/bin/cc -o \$\{library-file\} -shared -I\$\{src-path\} -I\$\{header-path\} -I\$\{header-solaris-path\} -KPIC \$\{library-file\}~' ./plugins/org.eclipse.update.core.solaris/src/build.xml 233,234d232 < perl -pi -e 's~arg value="-shared"~arg value="-G"~' ./plugins/org.eclipse.update.core.solaris/src/build.xml <
Also, here's some suggestions for making the script a little more robust: 1. Test whether the values for JAVA_HOME, J2SE15 and J2SE14 are correct. That is, can a rt.jar be found under the expected locations for each of these JDKs 2. Ensure that the 'ant' on the user's path is at least version 1.6 (the minimum required by the various build.xml files).
Hi Doug, Thanks very much for the diff and for the suggestions. You might also consider opening these as Issues on the Issues page. I'll give the -G flag a try this weekend and roll it in soon. ------Tim------
OpenSolaris? b96 x64, jdk1.6 x64, jdk1.5 x64, jdk1.4 x32 test pass.
Hello, I'm trying to build Eclipse 3.4 on SXDE 1/08 (b79a). It builds successfully but it seems it's not possible to install additional features like Java Development or Web and Java EE Development from the update manager. It always fails with:
An error occurred during provisioning.
Is there any workaround for this issue? Thanks! Karel
OK, what I've written above seems to apply only to eclipse-provisioned build. Once I used eclipse and enable old software manager I've been able to install what I need. Cheers, Karel
I'm using osol-0811-b98, trying to build Ganymede with above instructions. However, it fails building it. I reckon that the culprit is to be found in SunStudioExpress?: whatever I do with /opt/SunStudioExpress?/prod/bin/ube it will return "Killed" and error code 9. Has anyone any experiences to share? I have no idea how to proceed... Thanks! Manfred.
Hi Manfred, Currently, we have not tried on builds higher than svn90, but from a comment above it looks to pass on b96. Could you possibly post this as a defect and provide more detail about the error you are seeing -- any kind of a trace might help. Thanks. ------Tim------
Is there anything in the works for Eclipse 3.4.1 ?
Thanks so much to you guys for putting this cool script together! It works great!
Eclipse runs fine for me on Solaris finally, but now I get the stupid error when I try to go to "Help >> Software Updates" and get the evil error that says "CAnnot Launch the Update UI. This installation has not been properly configured for Software Updates."
Thanks for any suggestions on this one. --Bob
Thanks very much for the comments.
As for Eclipse 3.4.1, I have not yet tried to build it using the script. Now that my paying project is winding down a bit, I will attempt this soon. As a first try, I would probably perform the upgrade itself using the p2 update manager instead of doing a full build using the script. If that does not work, then I would do the full build.
As for the error about launching the Update UI, there are some comments above relating to that problem. The latest version of the script should take care of the p2 update problem. The last two commands provision the eclipse installation with the SDK profile. I would ask this -- are you running the eclipse version built in the /build/eclipse subdirectory or in the /build/eclipse-provisioned subdirectory? The eclipse version in eclipse-provisioned is the version that can use the p2 update manager.
If the last 2 commands for eclipse provisioning have failed in your build, a workaround would be to go to the eclipse preferences page and to enable the old Update Manager capability.
Hope that helps. ---Tim---
Tim, that worked great! Sorry for not reading the above statements earlier. Thanks so much! Now I am up and running with Eclipse 3.4 on Solaris and with standard Software Updates menu option working as it should!
Great to hear! As an update, I finally installed Solaris on my Mac Parallels last night, so I should get around to trying out the 3.4.1 build soon.
------Tim------
Tim; I think I have something wrong with my configuration where updates don't seem to "stick" after I restart. :(
For example, I can get the cool Apache DS LDAP Browser plugin (see http://directory.apache.org/studio/static/users_guide/ldap_browser/gettingstarted_download_install.html ) to install and work really well, but only if I choose "Apply Changes" at the very last part, even though the message strongly recommends restarting. Even still, after I exit eclipse and start eclipse again, the configuration is corrupted. At this point I can go into Manage Configurations, navigate to the Apache Directory Server LDAP Browser, select it, then click on the Properties link on the right, then click "Status" in the Properties box, it will tell me "No plug-in: "org.apache.directory.studio.ldapbrowser.core" included at runtime." and about 10 more similar errors related to the same product.
If I choose the "Yes" button on the last part (to restart), then eclipse restarts and I get the corrupted version right away.
One note is that when I am in the "Apply Changes" mode and the stuff is working, I can go to Help >> About Eclipse SDK, click on "Plugin Details" and see all the related plugins, including the signing info. But not after I close and restart. Then they are gone.
I am also getting about 12 of these stack traces in my .log file at about the time I click Apply "Changes":
!ENTRY org.eclipse.ui 4 0 2008-10-22 00:28:35.791 !MESSAGE Unhandled event loop exception !STACK 0 org.eclipse.swt.SWTException: Failed to execute runnable (java.lang.ArrayIndexOutOfBoundsException?: 1)
Caused by: java.lang.ArrayIndexOutOfBoundsException?: 1Thanks so much for sticking with me on this. --Bob
Hi Bob,
Great catch. I have had a chance to look at this, and it appears that the problem was related to the last two commands in the script. I will update the build script soon. Until then, you can run the following commands:
Now run the eclipse-provisioned/eclipse. From the update manager, add the following URLs to the Site Manager:
- http://download.eclipse.org/releases/ganymede
- http://download.eclipse.org/eclipse/updates/3.4
- http://directory.apache.org/studio/update/1.x
Now you should be able to install the LDAP Browser (or any other plug-in, for that matter) and it will stick if you re-start.Let me know if this helps. Thanks for your feedback.
------Tim-------
The build script has been updated (with both the -G correction from a comment above and with the p2 changes). Also note the recent changes section -- build scripts have now moved to the source repository under trunk/scripts. It would be nice to put a distro in the downloads section, but the current Google Code restriction on file size precludes that possibility for now.
Thanks, Tim! That worked perfectly! You are a real Solaris-Eclipse winner! Now I am cruzing with LDAP and I can start working through the super JNDI Tutorial and Reference! --Bob
The latest build script works with eclipse 3.4.1.
Thanks for the wonderful script, I am able to run the eclipse now. However I am facing some error while updating to JEE development environment, Following is the error i am getting (I am running from eclipse directory with Legacy Update enabled.)
Requested operation cannot be performed because it would invalidate the current configuration. See details for more information.
Thanks in advance.
Hi Medhyal, Is there any reason in particular you are not using eclipse-provisioned and the p2 update manager? Thanks. -------Tim-------
Thanks Tim, it is working properly with eclipse-provisioned.
Thanks for your great work Tim! I've been able to compile and run Eclipse 3.4.1 from the eclipse-provisioned directory. The new Update Manager is working perfect.
Always excellent to hear. Thanks, for the feedback, Volker!
Hi,
Can anyone give more details on how to get the following files:
SUNWant SUNWgnome-common-devel SUNWxwinc SUNWxorg-headers
I can't find the repository as mentioned above in the instructions.
Thanks Sebastian
Hi,
I have successfully built the 3.4.1 SDK from source distribution for Solaris/x86 with resources provided here. I'd like to add the Solaris/x86 components required to the 3.4.1 delta-pack. What is the best way to proceed? Any pointers?
Thanks.
Thanks very much for the feedback and for your interest in the project. By going into the eclipse-provisioned/plugins directory and running "ls | grep solaris", you should get the information you need for including the solaris-gtk-x86-specific jars in the delta pack:
It appears that there may also be some osgi security-related platform specific code in the most recent RCP delta pack, but these are not built by the solipse script (of course, it might be worth looking into, but to date has not caused problems). If this helps you to get the solaris-swt-gtk code into the eclipse delta pack, I would really like to hear about it. Thanks again.
--------Tim---------
Hi,
kudos to you guys for taking on this task! Thank you very much!
Yet, just a stupid question from a Solaris newbie: Are these instructions for OpenSolaris?? 2008.05 or for Solaris 10? In the latter case, I'll go along with Sebastians comment above - how do we access the Open Solaris repository? (We are not talking about sunfreeware.org or blastwave.org here, are we?)
And yet another question: Has anyone successfully tried using Eclipse Photran on Solaris x86? This is what I'd be using it for mostly (because SunStudio? Fortran support is lacking).
Cheers, Martin
Hi Martin,
Thanks very much for the interest in the project. The instructions above are mostly for OpenSolaris?. My own configuration is this: I have done this build on SXCE b91 and b103, neither of which requires the installation of the packages from the OpenSolaris? repository mentioned above. I will try to get Hugo to post a reply for getting packages out of the OpenSolaris? repository because I am not familiar with that process. For now, you might want to check here: http://dlc.sun.com/osol/docs/content/IPS/ggdcd.html The original script was actually developed to run eclipse on Nexenta and for that build, I did use sunfreeware.org so I am pretty confident that the packages there would be sufficient. Hugo's goal was to eliminate the need for sunfreeware or blastwave packages and to concentrate on using only what is available in the OpenSolaris? repository.
As for Photran, I have not tried that specific set of plug-ins, so I would be curious to hear about your experience with it. Unless it uses features specific to a particular OS, architecture and windowing system (which I would doubt) and unless it uses the SWT_AWT bridge (which I have heard might be buggy on a few OSs), I would bet it runs as well with solipse as with any other Eclipse distro.
Thanks again, I hope this post helps and happy solipsism!
------Tim------
Hi,
I'm running OpenSolaris? 2008.11 under VMware Fusion 2.0.1.
I managed to run the solipse_build.sh script ok and then tried to run eclipse-provisioned/eclipse but see the following exception stack trace on the console:
org.eclipse.core.runtime.AssertionFailedException: null argument: at org.eclipse.core.runtime.Assert.isNotNull(Assert.java:86) at org.eclipse.core.runtime.Assert.isNotNull(Assert.java:74) at org.eclipse.equinox.internal.provisional.p2.metadata.ProvidedCapability.<init>(ProvidedCapability.java:26) at org.eclipse.equinox.internal.provisional.p2.metadata.MetadataFactory.createProvidedCapability(MetadataFactory.java:189) at org.eclipse.equinox.internal.p2.metadata.repository.io.MetadataParser$ProvidedCapabilityHandler.<init>(MetadataParser.java:483) at org.eclipse.equinox.internal.p2.metadata.repository.io.MetadataParser$ProvidedCapabilitiesHandler.startElement(MetadataParser.java:469) at org.eclipse.equinox.internal.p2.persistence.XMLParser$AbstractHandler.startElement(XMLParser.java:171) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:501) at com.sun.org.apache.xerces.internal.parsers.AbstractXMLDocumentParser.emptyElement(AbstractXMLDocumentParser.java:179) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:377) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2747) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:140) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:510) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:807) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:107) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205) at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522) at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryIO$Parser.parse(MetadataRepositoryIO.java:193) at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryIO.read(MetadataRepositoryIO.java:56) at org.eclipse.equinox.internal.provisional.spi.p2.metadata.repository.SimpleMetadataRepositoryFactory.validateAndLoad(SimpleMetadataRepositoryFactory.java:116) at org.eclipse.equinox.internal.provisional.spi.p2.metadata.repository.SimpleMetadataRepositoryFactory.load(SimpleMetadataRepositoryFactory.java:85) at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:485) at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:452) at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:435) at org.eclipse.equinox.internal.p2.engine.MetadataCache.getRepository(MetadataCache.java:46) at org.eclipse.equinox.internal.p2.engine.MetadataCache$1.notify(MetadataCache.java:81) at org.eclipse.equinox.internal.p2.core.ProvisioningEventBus.dispatchEvent(ProvisioningEventBus.java:86) at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:211) at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:321)Any idea what's going wrong?
Hi Doug,
Have you tried running eclipse/eclipse (the non-provisioned version that is built by solipse)? From the look of the stack trace, my first impression would be that something went wrong in the build, but it is difficult to say just from the stack trace. Often, if there is a C-compilation problem (e.g., with the platform-specific SWT libraries), the build will not fail, but the platform-specific fragments will be missing from the final build. Could you prehaps go into the eclipse-provisioned/plugins directory and grep for any files or directories with "solaris" in the name? Thanks.
------Tim------
I get the same error when running the non-provisioned version except that it only shows up when I try to use Software Update. In particular, it shows up in the error log when I select Solipse 3.4.1 in the Installed Software tab of the Software Updates and Add-ons wizard and press Update.
Hi Tim,
I tried your suggestion and added the following to the delta-pack plugin directory:
With the delta-pack installed, when I try to export a product, on the second page of the product export wizard, I do not see option to export for solaris (gtk/x86).
Then I modified the following file:
and changed version for org.eclipse.equinox.launcher.gtk.solaris.x86 from 0.0.0 to 1.0.101.R34x_v20080731. Also, I copied the 'eclipse' executable from Solaris/x86 build at .../contributed/gtk/solaris/x86/launcher under the org.eclipse.equinox.executable feature.
Still, no PDE does not see it.
Here is what Eclipse help has to say about this:
that the RCP delta pack is installed in the target platform. When this option is selected, a second wizard page is available and displays a list of available platforms to export to. This list is compiled by navigating the directory structure of the installed org.eclipse.platform.launchers feature to retrieve the different platform combinations.The MANIFEST.MF & ECLIPSE.SF files under the org.eclipse.equinox.executable feature contains SHA1-Digest entries for the launcher and plugins that don't exist for Solaris/x86; I am not sure if this contributes to the problem.
If anyone else has any ideas to enable Solaris (gtk/x86) in the delta-pack, I'll give it a try.
Thanks.
I tried to perform the build on a Solaris 10 system (as opposed to OpenSolaris? 2008.11) and made it work. I had to re-apply the patches I suggested in an earlier comment to do with converting the -shared flag to -G for cc. Here's the patch again as taken against version r29 of solipse-build.sh:
235c235 < perl -pi -e 's~gcc\s*-o\s*\$\{library-file\}\s*-shared\s*-I\$\{src-path\}\s*-I\$\{header-solaris-path\}\s*-fPIC\s*\$\{library-file\}~$ENV{SUN_STUDIO_HOME}/bin/cc -o \$\{library-file\} -G -I\$\{src-path\} -I\$\{header-path\} -I\$\{header-solaris-path\} -KPIC \$\{library-file\}~' ./plugins/org.eclipse.update.core.solaris/src/build.xml --- > perl -pi -e 's~gcc\s*-o\s*\$\{library-file\}\s*-shared\s*-I\$\{src-path\}\s*-I\$\{header-solaris-path\}\s*-fPIC\s*\$\{library-file\}~$ENV{SUN_STUDIO_HOME}/bin/cc -o \$\{library-file\} -G -I\$\{src-path\} -I\$\{header-path\} -I\$\{header-solaris-path\} -KPIC \$\{src-path\}/*.c~' ./plugins/org.eclipse.update.core.solaris/src/build.xml 238a239,240 > perl -pi -e 's~arg value="-shared"~arg value="-G"~' ./plugins/org.eclipse.update.core.solaris/src/build.xml >By the way, the patch I just supplied also makes the build work on OpenSolaris?.
Hi Doug,
Boy do I have egg on my face! I could have sworn I merged your diff into the script, but it looks like that did not happen. Your change has been merged into the latest script (r32). You might want to verify just to make sure I did it right this time. Many apologies for the trouble you went through, and thanks for digging in and solving that problem again.
-----Tim-----
Hi,
Has anyone made a pkg out of this, that they would kindly share.
It would be a great help. Thanks. M
Hi Mamaji,
There had been a discussion about getting this pkg into the OpenSolaris? repository back for the November release, but no one followed up with Hugo or me. It is on the OpenSolaris? community's radar. If you would like to contribute such a package, I would wholeheartedly encourage that.
Thanks for your interest.
-------Tim-------
Hi, OpenSolaris? 2008.11 repo contains Eclipse build. IIRC it's not possible to find it from the GUI, but if you issue pkg install eclipse, it should work. It's some time I deleted OS 2008.11 VBox image here, so I'm not able to verify that now... Karel
Doug,
Could it be that some sites are down in the "Manage Sites..." list?
I have successfully built the Eclipse SDK for Solaris x86, thanks to the guidelines and patches provided here.
I can successfully launch eclipse when my JAVA_HOME is set to JRE6. But, when I set it to to JRE5, eclipse fails to launch. See log snippet below:
!SESSION 2009-02-21 09:06:46.211 ----------------------------------------------- eclipse.buildId=M20080911-1700 java.version=1.5.0_17 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=solaris, ARCH=x86, WS=gtk, NL=en Command-line arguments: -os solaris -ws gtk -arch x86 !ENTRY org.eclipse.equinox.common 4 0 2009-02-21 09:06:52.530 !MESSAGE !STACK 0 org.osgi.framework.BundleException: The activator org.eclipse.core.internal.runtime.Activator for bundle org.eclipse.equinox.common is invalid at org.eclipse.osgi.framework.internal.core.AbstractBundle.loadBundleActivator(AbstractBundle.java:146) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:980) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:346) at org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:355) at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1074) at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:616) at org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:508) at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:299) at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:489) at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:211) at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:321) Caused by: java.lang.UnsupportedClassVersionError: Bad version number in .class file at java.lang.ClassLoader.defineClass1(Native Method) ...Is this build meant to be used with JRE6 only?
I tried a variation in the solipse_build.sh without success: I set JAVA_HOME to point to JDK5, and I set JavaSE16 to point to JDK6 instead of JAVA_HOME.
Any ideas?
Thanks. Amir
Hi Amir, Great to hear that you have been able to build the eclipse distribution for OpenSolaris?! It appears that you have answered your own question -- yes, the build is meant to be used with Java 6. Thanks for your interest, ----Tim----
Hi Tim,
Thanks for your response.
Is there a reason why the Solipse build should only support Java6? The Eclipse distributions from Eclipse Foundation can be run with Java5 or Java6.
Thanks again. Amir
Hi Amir,
No.
----Tim----
excelent everything updated to WTP 3.0.4 with only problems with the jbosstools, but that's another thing
=D
Very happy to hear that! If you figure out what is happening with the JBoss tools, and if it is solipse-related, I would welcome any feedback. Thanks for the support!
---Tim---
is the visualtool and the xulrunner see it here http://www.jboss.org/index.html?module=bb&op=viewtopic&t=149729
Does internal browser works in solipse?
Thanks for the question. The internal browser currently is not supported. I have been able to get the xpcom and mozilla swt components to build, but whenever I try to enable the internal browser, I get a relocation error. I am pretty much blocked at this point.
---Tim---
If problem in building xulrunner and xpcom under solaris, some info can be founed here(http://dynamicproxy.livejournal.com/14542.html) or i can build xulrunner and provide it's for community :-). How I can enable building internal browser in build script? I think it's will be a good if we will not modify script, but create some property file where specify locations of java 1.4, 1.5, 1.6 , CC compiler and other properties. In eclipse sources such file already exists. Also why we should replace build.xml and not use provided from eclipse?
Thanks for your input. If you take a look at the build script, there are a whole bunch of s/// lines commented out -- these are the lines that will allow you to build the SWT browser binaries (they are a bit out-of date and need very slight modification from what is in SVN). The problem I am seeing is not in building firefox or xulrunner, which I have been able to install and use successfully with the standard mozilla instructions (https://developer.mozilla.org/en/Solaris_Build_Prerequisites). I am able to compile against my dev firefox installation, but when I try to enable my internal SWT browser, I get a relocation error / unresolved symbol from the xpcom library.
As for the problem with the build.xml file, please see https://bugs.eclipse.org/bugs/show_bug.cgi?id=221908 for an explanation of what happened -- the compileLibs Ant task has been removed from the build.xml file.
Let me know if you need any more information.
---Tim---
Thanks for answer. One more questuin, initialy i have tried to run script when i haven't install cc compiler at all, and it's doesn't stop on error, it's will be good it stops an error to awoid incorrect eclipse build. --Maksim Areshkau--
Also in script used sunwspro, but when i have installed sunstudioexpress, /opt/SUNWspro doesn't appers on my solaris installation. I have tried to change SUN_STUDIO_HOME to my sunstduionexpress installation and it's doesn't compiled. Only when I have created soft link with name SUNWspro -> sunstudioexpres, it's has compiled succesfully.
Hi Maksim,
Thanks for the info, and you make a good point. You are quite right that the build will not stop on error if the cc compiler does not exist. It was not my intention to include error-checking code in the script because the build instructions indicate what dependencies need to be installed. Also, this script should not be expanded much beyond its current form, except for tweaks as new Eclipse versions are released. The script is a hack, no doubt. Rather than put in time gilding the pig, it would be better just to fix the actual Eclipse build for solaris-gtk-x86 or to use this script to build real distributions (such as the one currently in the Open Solaris repository, which is using this script and is being updated to use the proper p2-provisioned distribution that this script creates), and that won't happen until enough people vote on the Eclipse bug for making this Solaris distro official.
It's not a script for the faint of heart -- if it works for you, then great; if it doesn't, then I'll try to help, but I can't support all the different solaris configurations out there.
Thanks for the feedback and keep it coming!
---Tim---
Some question: How i can build only Platform Runtime Binary whis update manager? I not need any plugins.
I have the feeling you might be able to do this by modifying the p2 packaging command. Has your investigation into p2 yielded any luck?
---Tim---
No, Any my attempt was not successful. I try set installUI "org.eclipse.platform", but no result.
I have anouter problem. When i open any file in Eclipse under OpenSolaris?, editor always show change in file. But i no chane nothing. How fix it?
Looks like Solaris x86 might be supported by Eclipse after all! See http://www.eclipse.org/swt/R3_5/new_and_noteworthy.html#m7
Thanks for the update. I will happily try it out.
Hi,
Any status for Eclipse 3.5.x on opensolaris? Thanks!
Hi Ludovic, Have you tried the official solaris-gtk-x86 distribution from eclipse.org. It should work with opensolaris as well. Let me know if this is or is not the case. Thanks!
@timezra: yep, you are correct, the sol10 gtk x86 also works fine with OpenSolaris?!!!
Great