Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #429343 +++ This bug is to provide a native 64-bit version of Eclipse for Solaris SPARC. This is necessary because Eclipse Neon (4.6) mandates the usage of Java 8 JRE which is only available as 64-bit on Solaris SPARC.
The SPARC machine we were planning to use has been down since last week and I'm still waiting for it to be brought back up, even if that happens today, it might be too late for M7, so moving this to RC1 (all the work on the fragments and build scripts is done, only the binaries need to be rebuilt).
Dani, Would this need a PMC approval for RC1? Not sure if it will count as feature work or not...
(In reply to Arun Thondapu from comment #2) > Dani, > > Would this need a PMC approval for RC1? Not sure if it will count as feature > work or not... +1 for RC1.
(In reply to Arun Thondapu from comment #1) > The SPARC machine we were planning to use has been down since last week and > I'm still waiting for it to be brought back up, even if that happens today, > it might be too late for M7, so moving this to RC1 (all the work on the > fragments and build scripts is done, only the binaries need to be rebuilt). I've finally managed to build all the necessary pieces for this but I do not want to push them into a real I-build without a local test build first. Moving to RC2... David, I will merge the patches for launcher and SWT after RC1 is declared and update here so that we will have time to make the releng changes and do some local test builds, if needed.
New Gerrit change created: https://git.eclipse.org/r/73101
(In reply to Eclipse Genie from comment #5) > New Gerrit change created: https://git.eclipse.org/r/73101 I have submitted this change to Gerrit just to have it "stashed" away. (I voted -1 on it so it is not blindly committed. It can only be committed after the addition to the equinox.executable feature. I've not seen or heard anything about the launchers and swt being added for RC2, though I know earlier today that was the plan. My "draft" changes might be enough to allow the build to pass, or get most of the way through, but there are undoubtedly errors, depending on a number of factors. The main "new" thing it has (required to build, once equinox.executable.feature has been changed) is the addition to our "target environment" of <environment> <os>solaris</os> <ws>gtk</ws> <arch>sparcv9</arch> </environment> Other than that, I half-blindly changed "sparc" to "sparcv9" in the rest of the scripts ... with the other half being careful tweaks to names and directories.
(In reply to David Williams from comment #6) > I've not seen or heard anything about the launchers and swt being added for > RC2, though I know earlier today that was the plan. Sorry for the delayed update David, I was planning to do it yesterday but the launchers needed to be rebuilt yet again to pick up the fixes for bug 493797 (which was also fixed just yesterday) and ran into connectivity problems with the SPARC build machine. > The main "new" thing it has (required to build, once > equinox.executable.feature has been changed) is the addition to our "target > environment" of > > <environment> > <os>solaris</os> > <ws>gtk</ws> > <arch>sparcv9</arch> > </environment> > > Other than that, I half-blindly changed "sparc" to "sparcv9" in the rest of > the scripts ... with the other half being careful tweaks to names and > directories. The arch value should be "sparc64" and not "sparcv9" as that is the value the launcher and swt fragments have been created with (more for the sake of consistency with other fragments than any other reasons).
(In reply to Arun Thondapu from comment #7) > (In reply to David Williams from comment #6) > > I've not seen or heard anything about the launchers and swt being added for > > RC2, though I know earlier today that was the plan. > > Sorry for the delayed update David, I was planning to do it yesterday but > the launchers needed to be rebuilt yet again to pick up the fixes for bug > 493797 (which was also fixed just yesterday) and ran into connectivity > problems with the SPARC build machine. I'm working with the team which owns the machine in getting it back online and I'm hoping we can commit the launcher and swt fragments for the RC2 rebuild planned for later today, will keep you posted...
(In reply to Arun Thondapu from comment #8) > (In reply to Arun Thondapu from comment #7) > > (In reply to David Williams from comment #6) > > > I've not seen or heard anything about the launchers and swt being added for > > > RC2, though I know earlier today that was the plan. > > > > Sorry for the delayed update David, I was planning to do it yesterday but > > the launchers needed to be rebuilt yet again to pick up the fixes for bug > > 493797 (which was also fixed just yesterday) and ran into connectivity > > problems with the SPARC build machine. > > I'm working with the team which owns the machine in getting it back online > and I'm hoping we can commit the launcher and swt fragments for the RC2 > rebuild planned for later today, will keep you posted... FYI, the build machine is finally back! I should be done with the rebuilds in the next few minutes.
There has been some questions on what is the proper "architecture name" for Sparc 64-bit, so thought I would document some references here. According to https://www.osgi.org/developer/specifications/reference/ it should be 'sparcv9' Also, this document implies 'sparcv9': https://docs.oracle.com/cd/E19683-01/806-6543/compare-3/index.html But Tom said what really matters is the "os.arch" property return from the VM, and pointed to a utility we should be able to run on the system to find out. https://osgi.org/download/properties.jar But none of us can get that to run (there must be some more "instructions" or something, for it?) Another "easy", non-standard way, to see "system properties" (that works for Oracle's VM, at least) is to use -XshowSettings java -XshowSettings 2>&1 | tee out.txt Using that, my "intel" linux box shows os.arch = amd64 Which OSGi calls an alias of x86_64 At least for Felix, see http://felix.apache.org/documentation/subprojects/apache-felix-framework/apache-felix-framework-configuration-properties.html Is says "Note that the framework does not use system properties to find its configuration properties, it only consults the map passed into its constructor". So, complicated. :)
Gerrit change https://git.eclipse.org/r/73101 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=3d8e38e44f286d549f626f2995790294272bf604
(In reply to David Williams from comment #10) > There has been some questions on what is the proper "architecture name" for > Sparc 64-bit, so thought I would document some references here. > > According to https://www.osgi.org/developer/specifications/reference/ > it should be 'sparcv9' > > Also, this document implies 'sparcv9': > https://docs.oracle.com/cd/E19683-01/806-6543/compare-3/index.html > > But Tom said what really matters is the "os.arch" property return from the > VM, > and pointed to a utility we should be able to run on the system to find out. > > https://osgi.org/download/properties.jar > > But none of us can get that to run (there must be some more "instructions" > or something, for it?) > > Another "easy", non-standard way, to see "system properties" (that works for > Oracle's VM, at least) is to use -XshowSettings > > java -XshowSettings 2>&1 | tee out.txt > > Using that, my "intel" linux box shows > os.arch = amd64 > Which OSGi calls an alias of x86_64 > > > At least for Felix, see > http://felix.apache.org/documentation/subprojects/apache-felix-framework/ > apache-felix-framework-configuration-properties.html > Is says > "Note that the framework does not use system properties to find its > configuration properties, it only consults the map passed into its > constructor". > > So, complicated. :) I have confirmed that os.arch = sparcv9 by running the above command on the SPARC machine. I have also changed all references from sparc64 to sparcv9 in both the launcher and the SWT fragments. David, I have pushed the fragments, we can try a build now since your patch is also merged.
(In reply to Arun Thondapu from comment #12) > > David, I have pushed the fragments, we can try a build now since your patch > is also merged. My local build test build has not failed yet. And, maybe it won't? But, I noticed some oddities so made me look closer, and it seems to me the launcher and swt fragments have not been added to the org.eclipse.e4.rcp feature. (that's in eclipse.platform.ui). It seems others are listed there ... so ... sparcv9 too? Or, we can wait until my local build is completely done. Just thought I would mention it now.
(In reply to David Williams from comment #13) > (In reply to Arun Thondapu from comment #12) > > > > > David, I have pushed the fragments, we can try a build now since your patch > > is also merged. > > My local build test build has not failed yet. And, maybe it won't? But, I > noticed some oddities so made me look closer, and it seems to me the > launcher and swt fragments have not been added to the org.eclipse.e4.rcp > feature. > (that's in eclipse.platform.ui). > > It seems others are listed there ... so ... sparcv9 too? > My local build actually did complete, but the sparcv9 "products" (e.g SDK) did not have SWT in them. They did have the launcher but might need those named in the feature for those building RCP apps, or similar.
New Gerrit change created: https://git.eclipse.org/r/73236
Gerrit change https://git.eclipse.org/r/73236 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=9329b4a757a4091c5bd1d4af695ff47e4f211f6b
Marking as fixed. If minor quirks are still wrong (such as links on DL page) I'll open new bugs for those.
*** Bug 294718 has been marked as a duplicate of this bug. ***
