My Nexenta upgrade coincided nicely with the release of Eclipse 3.4M5. Because I had to re-install Eclipse anyway, and because a shiny new Nexenta install deserves nothing less than the latest-and-greatest Eclipse release, I downloaded the M5 source, installed the Eclipse build dependencies, ran my 3.4M4 modification script and with a few minor tweaks was quickly able to get Ganymede up and running, Java editor bread-crumb saccharine and all.
The script for building Eclipse 3.4 M5 for solaris-gtk-x86 can be downloaded from the solipse downloads page. Please be aware of the Nexenta-specific instructions for building the SWT library with gcc instead of SunStudio cc.
Breadcrumbs in the Java Editor are one of the sauciest additions to this latest release. Even though they do not add functionality that is not already in the workbench and they occupy precious screen real estate, they are great eye candy.
12 comments:
I've tried applying this script but get compilation errors such as:
[javac] 656. ERROR in /tmp/dsimon/plugins/org.eclipse.jdt.debug/jdi/org/eclipse/jdi/internal/ByteValueImpl.java (at line 29)
[javac] public class ByteValueImpl extends PrimitiveValueImpl implements ByteValue {
[javac] ^^^^^^^^^^^^^
[javac] The interface Comparable cannot be implemented more than once with different arguments: Comparable and Comparable<ByteValue>
Even though these error messages imply it's a javac error, I believe the compilation is actually done by ecj.jar (i.e. the JDT batch compiler). Is there some switch for ecj to make it more tolerant when compiling code that mixes generified and raw classes? And if so, where would I apply the switch?
Hi Doug. Thanks for your comment. Do you mind if I ask what version of the JDK you are using?
I've tried both jdk1.6.0_01 and jdk1.6.0_04. I should also note that I'm doing this on a Solaris 10 AMD64 machine even though I doubt that makes any difference.
Hi Doug,
Thanks for checking that. It is an interesting problem and one that I have not encountered.
My first instinct was to think perhaps there might be a classpath issue because Eclipse packages the un-generified com.sun.jdi classes in one of its own plugins, while sun provides similar generified versions of the classes in the Hotspot jdk/lib/tools.jar. Just to make sure, you wouldn't happen to have the tools.jar on your classpath by any chance, would you?
Aside from that, I would say that using an amd64 very well might be a contributor to the difference between our results since sun has special binaries for amd64 and since 64-bit architecture is treated slightly differently by the PDE build process (the depths of those differences I cannot speak to off-the-cuff).
Finally and unfortunately, I do not have an answer to the original question you posted, but I would be very curious to hear an answer if there is one out there.
If you have any more information that might help clarify what is going on, please let me know.
Thanks.
So, I finally got this to work. Your intuition about tools.jar being on my default classpath was spot on: I had copied tools.jar into $JAVA_HOME/jre/lib/ext to simplify another project I'm working on. Not a good idea!
My next hurdle was that pkg-config on my system was adding a flag (-mt) that gcc does not understand. After reading up on pkg-config, I found that the offending file was:
/usr/lib/pkgconfig/gthread-2.0.pc
I simply deleted the "-mt" flag from both the "Libs:" and "Cflags:" lines in this file.
Next I had to edit the line of your script that start with:
perl -pi -e 's~gcc -o \$\{library-file\} -shared -I\$\{src-path\} -I\$\{header-solaris-path\} ...
to have an extra space after the "-o" (which shows how brittle this method of patching is)! I also had to add the following line:
perl -pi -e 's~arg value="-shared"~arg value="-G"~' ./plugins/org.eclipse.update.core.solaris/src/build.xml
to deal with the fact that "-shared" is not a valid flag for cc - I'm surprised you didn't hit this.
In any case, I would have been absolutely lost without your original script - thanks a lot!
One suggestion I have is that you use environment variables for the hard coded paths (/export/home/timezra/opt/jdk1.6.0_02 and /export/home/timezra/opt/SUNWspro). In fact, JAVA_HOME is most likely already defined.
Hi Doug,
Thanks very much for the feedback, and whew! I'm glad to hear that the script and comments were helpful as a starting point and that you were able to sort things out to get the build working on your machine.
I totally agree about the hard-coded paths -- the script was originally for my own personal use, but since it looks like a few of you out there have come across it, it might be time to button it up.
Great catch on the cc flag -- it had not cause any build failures on my machine but probably did not help anything.
As of right now, I am trying to build on Solaris Express and running into some issues with compiling SWT with Mozilla / Firefox support.
If you discover anything else, let me know as I would be happy to hear about it!
Thanks.
Hi thanks very much for your mods, I was able to compile eclipse but I find I cannot install the Eclipse XML Editors and Tools because it fails with this error
Update operation has failed
Error retrieving "plugins/org.eclipse.swt.gtk.solaris.x86_0.0.0.jar". [Server returned HTTP response code: "404 Not Found" for URL: http://www.mirrorservice.org/sites/download.eclipse.org/eclipseMirror/releases/ganymede/plugins/org.eclipse.swt.gtk.solaris.x86_0.0.0.jar.]
Server returned HTTP response code: "404 Not Found" for URL: http://www.mirrorservice.org/sites/download.eclipse.org/eclipseMirror/releases/ganymede/plugins/org.eclipse.swt.gtk.solaris.x86_0.0.0.jar.
Obviously it doesn't exist :-) but since I've compiled it for eclipse, is it possible to point the update manager to my local version?
Hi Jander,
Thanks for the comment, and it's good to hear that you were able to get an initial install compiled and running.
I had not encountered this problem before. One quick question: are you using the Update Manager to install new components or to update existing components?
The first thing I would think offhand is that this may be related to the changes in the Eclipse Update Manager between M5 and M6 with the introduction of P2. I have not had a problem installing components from the Ganymede discovery site but have not installed components since the M5 release, and I have been a bit reluctant to compile Eclipse because of P2's initial instability. It appears that may be necessary now. Unfortunately, I will not be able to get to it until this weekend. If you discover anything in the meantime, I would be really interested in hearing about it.
Thanks again,
------Tim------
Hi Tim,
I'm using Eclipse Update Manager to install new features.
I'm not using Nexenta btw, but OpenSolaris, with SunStudioExpress and gtk packages from blastwave :-)
Hi Jander,
Quick update on this. I was able to compile 3.4RC2 on OpenSolaris this weekend and get the workbench running. Unfortunately, "Could not locate the running profile instance" appears in the error log, and I could not use the P2 update manager at all. As I reckoned, something with P2 is not being configured correctly. I will be looking at the problem this week, but if worse comes to worst, we might just be able to Disable P2 and re-enable the original Update Manager.
-----Tim------
Any further luck trying to build the 3.4 release? In particular the source build available at:
http://www.eclipse.org/downloads/download.php?file=/eclipse/downloads/drops/R-3.4-200806172000/eclipse-sourceBuild-srcIncluded-3.4.zip
Hi Doug,
Good to hear from you. Check this out:
http://timezra.blogspot.com/2008/06/solipse-for-building-eclipse-on-solaris.html
There is now a project in Google code for this. You might also try this distro that Hugo put up and I tested on a clean install of SXCE b91:
http://www.calendarian.net/tim/
So, to answer your question, yes I have been able to build and use Ganymede with a few restrictions (you have to enable the old update manager in Capabilities and the internal browser is not yet there).
Let me know if you got some use out of this!
-------Tim------
Post a Comment