Community
Participate
Working Groups
Created attachment 240410 [details] Patch for enabling a 64-bit build of Eclipse for Solaris/X86_64 This is the final patch in a series of patches I just added to be able to build a native 64-bit version of Eclipse for Solaris X86.
Created attachment 240411 [details] Patch for native build for Solaris X86_64 Don't know if this is necessary, but this patch contains the changes I made in the eclipse.platform.releng submodule.
I just discovered that the resulting build only starts when I add the parameter "-d64" to the build's eclipse.ini file at the end to the laucher's VM arguments. Otherwise an attempt is made to load the 32-bit JVM library into the 64-bit binary which obviously doesn't work...
Ready for first dumb question? What's difference between 'sparc' and solaris/x86_64? 'sparc' a different chip architecture and solaris/x86_64 specifically for intel?
(In reply to David Williams from comment #3) > Ready for first dumb question? What's difference between 'sparc' and > solaris/x86_64? > > 'sparc' a different chip architecture and solaris/x86_64 specifically for > intel? That's correct, sparc and x86 are 2 different architectures.
(In reply to Thorsten Heit from comment #2) > I just discovered that the resulting build only starts when I add the > parameter "-d64" to the build's eclipse.ini file at the end to the laucher's > VM arguments. Otherwise an attempt is made to load the 32-bit JVM library > into the 64-bit binary which obviously doesn't work... Do you know how to fix this? (in build). You'll need a p2.inf file in the fragment's META-INF directory, with special install instructions. (and matching uninstall). The only other one I know of we need to do something "special" is for rt.equinox.framework/bundles/org.eclipse.equinox.launcher.gtk.hpux.ia64 though there, we are setting permissions. Or, maybe it is a "touchpoint"? We do some similar things at the "SDK level", and maybe that's where this special setting belongs too ... but if at all possible, I prefer "those that need special things" to do it at "their" level. So, would want to try that first. For examples, see around http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/eclipse.platform.releng.tychoeclipsebuilder/sdk/sdk.p2.inf#n64 and read up on on the general topic at http://help.eclipse.org/kepler/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Fguide%2Fp2_customizing_metadata.html
(In reply to David Williams from comment #5) > > Do you know how to fix this? (in build). > > You'll need a p2.inf file in the fragment's META-INF directory, with special > install instructions. (and matching uninstall). Yesterday when I added the entry to Bugzilla I didn't had the time to investigate further. I'll look at this on monday when I'm back at work and have access to the machine. Thanks for your informations.
I added another patch to bug #429335 that adds "-d64" to the launcher VM arguments. Thanks again David for your hints.
Created attachment 240455 [details] Screenshot of the self-built Eclipse 4.4 on Solaris/GTK X86_64 This is a screenshot of the Eclipse application I just built for Solaris/GTK X86_64, displaying the Welcome view.
Created attachment 240457 [details] Screenshot of the "About Eclipse SDK" dialog window This is the screenshot of my Eclipse's About dialog (Help -> About Eclipse SDK).
Created attachment 240458 [details] Screenshot of installation configuration This is a screenshot showing the configuration details for my Eclipse build (Help -> About Eclipse SDK -> Installation Details -> Configuration tab).
Created attachment 240459 [details] The full configuration details These are the full configuration details of Eclipse on Solaris GTK/X86_64 I copied from the configuration dialog tab.
I'd like to make the following proposal regarding this contribution (that is, all the related contributions, not just this bugzilla entry). As much as we appreciate it receiving it, it seems a bit late to "release for Luna" ... if nothing else, there is too little time for proper "community testing and feedback". But, it seems reasonable to "get into the Git repos" over the next week or two, so that people can "build it themselves" if they want, using the "CBI build". We can look at adding some logic, perhaps using a profile?, that would "enable" it, or not ... but do not think we can confidently provide it on our download pages, etc. Thorsten, I'm not sure who you work for or what "business needs" you have for this distribution, but assume in addition to this initial contribution, you commit to testing it, and maintaining it over time? The other thing I'll need to check on, is if this needs to run through the "large contribution CQ process". That is, I should "count lines of code" to see if over 250 lines or not. I've not looked closely, but assume, Thorsten, that you've made few (if any) changes to "source"? That its mostly a matter of "compiler settings" and the like? Lastly, given that "64 bit is the future" do you think there is still a need for the Solaris 32 bit version? Or, asked another way, from your point of view, is there a time (next year?) that we can "retire" the 32 bit version?
(In reply to David Williams from comment #12) > Thorsten, I'm not sure who you work for or what "business needs" you have > for this distribution, but assume in addition to this initial contribution, > you commit to testing it, and maintaining it over time? One example that came up on status call ... if/when some code with launcher or SWT changes, "we" do not have the machines needed to "rebuild the binaries". Is that something you'd do, Thorsten? Or is there a cross-platform build solution we don't know about?
(In reply to David Williams from comment #12) > Thorsten, I'm not sure who you work for or what "business needs" you have > for this distribution, As far as I can tell the upcoming Java 8 seems to be 64-bit only on Solaris; even the newest build #132 doesn't contain any 32-bit executables/libraries. If you only have Java 8 on a Solaris machine, you won't be able to run Eclipse anymore. > but assume in addition to this initial contribution, > you commit to testing it, and maintaining it over time? I have done this patch in my spare time, but I'll try. > The other thing I'll need to check on, is if this needs to run through the > "large contribution CQ process". That is, I should "count lines of code" to > see if over 250 lines or not. I've not looked closely, but assume, Thorsten, > that you've made few (if any) changes to "source"? That its mostly a matter > of "compiler settings" and the like? I haven't changed anything in any source code, especially there was no need for as far as I can tell. Only a few build scripts, property files and the Solaris make file for SWT were patched. So yes, only compiler settings and the like. > Lastly, given that "64 bit is the future" do you think there is still a need > for the Solaris 32 bit version? Or, asked another way, from your point of > view, is there a time (next year?) that we can "retire" the 32 bit version? I can't speak for others, but personally I don't mind retiring the 32bit version in the future.
(In reply to David Williams from comment #13) > One example that came up on status call ... if/when some code with launcher > or SWT changes, "we" do not have the machines needed to "rebuild the > binaries". Is that something you'd do, Thorsten? Or is there a > cross-platform build solution we don't know about? Do you have a machine / system for creating the 32-bit-binaries for Solaris? If yes: Is this box running some version of Solaris? If the answer is yes, then you're almost done. As far as I know you only have to add the flag "-m64" to your compiler command line to let it produce 64-bit binaries, even on 32-bit machines. In case of no: How do (did) you create the binaries? Via cross-compiling from another system?
Created attachment 246091 [details] patch for eclipse.platform.releng.aggregator to enable native builds for Solaris x86/x86_64 This patch is made with "git diff" and contains the changes I made in the aggregator to allow for building a native version of Eclipse on Solaris x86_64 Source code branch: R4_4_maintenance
Created attachment 246092 [details] patch for eclipse.platform.releng to enable native builds for Solaris x86/x86_64 This patch is made with "git diff" and contains the changes I made in the eclipse.platform.releng submodule to allow for building a native version of Eclipse on Solaris x86_64 Source code branch: R4_4_maintenance
Created attachment 246094 [details] patch for eclipse.platform.ui to enable native builds for Solaris x86_64 This patch is made with "git diff" and contains the changes I made in the eclipse.platform.ui submodule to allow for building a native version of Eclipse on Solaris x86_64 Source code branch: R4_4_maintenance
Created attachment 246095 [details] Shell script to apply the patches This shell applies the patches to the aggregator and eclipse.pde.build / eclipse.platform.ui submodules so that a native version of Eclipse can be built for Solaris x86_64. As mentioned in bugs #429332, #429335 and #429342: - The patches were made against the R4_4_maintenance branch. - The script assumes that the patches reside in the same directory as the script itself. - Apart from executing the script, there's nothing else to do.
Created attachment 246096 [details] Screenshot of the self-built Eclipse 4.4 on Solaris/GTK x86_64
Created attachment 246097 [details] Screenshot of the "About Eclipse SDK" dialog window
Created attachment 246098 [details] Screenshot of the installation details dialog
Created attachment 246099 [details] Screenshot of the dialog showing the installed features
Created attachment 246100 [details] The full configuration details
Created attachment 246101 [details] Screenshot of the installation details dialog
Created attachment 246102 [details] Screenshot of the "About Eclipse SDK" dialog window
Created attachment 246126 [details] patch for eclipse.platform.releng.aggregator to enable native builds for Solaris x86/x86_64 (master branch) This patch is basically the same as the eclipse.platform.releng.aggregator.patch, but adapted to be applicable to the master branch. The only difference is that in the file production/build-functions.shsource from the master branch the indentation characters were changed slightly so that the original patch could not be fully applied. To have the script use this patch, simply omit the "master-" prefix from the file name, i.e. save it to disc as "eclipse.platform.releng.aggregator.patch".
(In reply to Thorsten Heit from comment #14) > (In reply to David Williams from comment #12) > > > but assume in addition to this initial contribution, > > you commit to testing it, and maintaining it over time? > > I have done this patch in my spare time, but I'll try. > Hi Thorsten, just wanted to "touch base" and make sure you knew this bug hasn't slipped through the cracks ... yet ... at least for Mars release. I think the "key" is getting you, or someone, to firmly commit to supporting this in the future ... more than "spare time" and "I'll try" (no offense). I know the PMC has been "asking around" to see if there is a large company that would want to join-in this effort, but I guess it has not bubbled up on anyone's top priority list yet. I am curious ... what motivated you do do this work? You mentioned "in spare time", but as far as I know, "Solaris" is not exactly a "hobby" machine that someone has sitting around their basement. Do you do independent consulting work on Solaris machines? Does your company have "internal Eclipse applications" that run on Solaris? [And, I don't mean to pry into your privacy or anything confidential, so feel free to say "can't answer that" if I am asking too much.]. Just asking trying to get a feel for a) how important this is to you (and/or your company) and b) a better, more detailed statement of long term commitment. [And, not asking for a firm contract or anything ... just more a firmer statement about your plans and ability to support in foreseeable future. One way for you to think about it, is if you could not do it, we might simply "drop it" ... so if that happened, who and how much would that impact community? Thanks for any additional information.
(In reply to David Williams from comment #28) > I know the PMC has been "asking around" to see if there is a large company > that would want to join-in this effort, but I guess it has not bubbled up on > anyone's top priority list yet. > Yes, the PMC is interested in this. Our main concern is to have a machine available at hand when needed, e.g. for testing and for rebuilding the binaries. I'm in contact with Oracle regarding this. We should fold this into bug 442266.
*** Bug 442266 has been marked as a duplicate of this bug. ***
(In reply to Dani Megert from comment #29) > Yes, the PMC is interested in this. Our main concern is to have a machine > available at hand when needed, e.g. for testing and for rebuilding the > binaries. I'm in contact with Oracle regarding this. So far, there was no success with this. I've now talked to Eclipse Foundation, and they will investigate whether they can provide us a virtual machine via OSU OSL (https://osuosl.org/).
> So far, there was no success with this. I've now talked to Eclipse > Foundation, and they will investigate whether they can provide us a virtual > machine via OSU OSL (https://osuosl.org/). No dice, they do not have any Solaris/SPARC plarforms at all. They did refer me to the GCC compile farm: https://gcc.gnu.org/wiki/CompileFarm GCC does not seem to provide a complete virtualized environment; the release engineer provides their SSH keys and goes about their business: From the above doc: If you are working on a piece of free software (GCC or any other GPL, BSD, MIT, ...) and need ssh access to the farm for compilation, debug and test on various architectures you may apply for a GCC Compile Farm account. Please send: your ssh protocol 2 public key ($HOME/.ssh/id_dsa.pub or id_rsa.pub) in attachment and not inline in the email AND your preferred UNIX login (see below User Accounts for already taken logins) AND at least one free software project you are a contributor of, with URLs pointing to your contributions and project licence information AND the email Subject should start with "[CFARM-REQUEST]" to laurent at (snip) After approval and account creation the compile farm machines should be used only for free software development, see this free software license list.
(In reply to Denis Roy from comment #32) > They did refer me to the GCC compile farm: > https://gcc.gnu.org/wiki/CompileFarm Unfortunately, I don't think that is going to work, as Solaris is not on their list of supported operating systems.
I should add that I am trying a few additional contacts that I have at Oracle to see if I can get access to a 64-bit Solaris machine.
(In reply to Mike Milinkovich from comment #34) > I should add that I am trying a few additional contacts that I have at > Oracle to see if I can get access to a 64-bit Solaris machine. Thanks!
(In reply to Mike Milinkovich from comment #34) > I should add that I am trying a few additional contacts that I have at > Oracle to see if I can get access to a 64-bit Solaris machine. Regrettably, my attempts to get any interest or support from Oracle have all failed. There does not seem to be anyone in the Solaris group that is interested in helping.
I know there is still some interest in this, but do not know if anything will be done for "Neon", and for sure will not be done for M3, so unsetting the milestone target for now. We can set it to something specific, once there is a plan.
(In reply to David Williams from comment #37) > I know there is still some interest in this, but do not know if anything > will be done for "Neon", and for sure will not be done for M3, so unsetting > the milestone target for now. We can set it to something specific, once > there is a plan. This is on our official plan.
Not sure why this was set to M4 unless someone knows something I don't. But, since only a week or 10 days left for M4 development, M4 seems unlikely. Arun, I believe your team is "next" on the critical path? To build binaries for executables and SWT? So ... please update milestone target when ready. The remaining changes to build will be fairly easy once those binaries are being built. (If/when they are built.)
(In reply to David Williams from comment #39) > Not sure why this was set to M4 unless someone knows something I don't. You could have figured it out by looking at the dependent bugs which cover SWT and the launcher and which have been set to M4 by Arun with the following statement: " I've started working on this item but won't be able to complete it in time for M3, planning for early M4... " Arun, where are you with that work? I agree with David, that it is probably too late for M4.
(In reply to Dani Megert from comment #40) > (In reply to David Williams from comment #39) > > Not sure why this was set to M4 unless someone knows something I don't. > > You could have figured it out by looking at the dependent bugs which cover > SWT and the launcher and which have been set to M4 by Arun with the > following statement: > " > I've started working on this item but won't be able to complete it in time > for M3, planning for early M4... > " > > Arun, where are you with that work? I agree with David, that it is probably > too late for M4. Sorry I missed responding to this, ran into some configuration setup issues on the machine we were planning to use for the builds and got delayed for M4, should get done in M5...
Since haven't seen others requried changes for this, assuming it won't be in M6, and perhaps not in 4.6?
(In reply to David Williams from comment #42) > Since haven't seen others requried changes for this, assuming it won't be in > M6, and perhaps not in 4.6? David, I was targeting to deliver this in M6 itself and did spend time working on it but couldn't manage to build all the necessary components in time for M6 (the launcher binaries are built and most of the SWT libraries are also built but there are a few more components involving native code that needed to be also rebuilt to have a full eclipse build). I believe we can have it close to completion by next week or so... Also, we cannot drop this item from 4.6 as the current 32-bit Solaris builds we provide for Neon are pretty much "useless" since Java 8 is only available as 64-bit on Solaris. So, I would vote for delivering this in 4.6 itself (obviously M7 that would be). Let me know if there are any specific concerns from your side?
I'm rebuilding all the binaries and libraries because I used the gcc toolchain the last time around, but I think it makes sense to use the Sun Studio toolchain which is what we were always doing on Solaris. The launcher binaries are already pushed to git and the SWT and other native components should be done by later today.
(In reply to Arun Thondapu from comment #43) > Let me know if there are any specific concerns > from your side? No. No concerns at all. But, I should do a number of "local" builds first as this is the sort of thing that is hard to "get right" (completely) the first time through. I may get a chance to start on it today, but fear most will need to wait until the weekend (I'm only working a little Thursday and Friday, since it is the end of our "spring break" in local schools). I suggest to tentatively try to have in next week's I-build (which means it needs to be in Sunday's Nightly, IMHO. Now you let me know if that is unrealistic. :)
(In reply to David Williams from comment #45) > No. No concerns at all. Thanks! > But, I should do a number of "local" builds first as this is the sort of > thing that is hard to "get right" (completely) the first time through. Sure, I'm aware of that, and just to be explicit we'll need to do this twice - first for the x86 64-bit build and then for the SPARC 64-bit build. > I suggest to tentatively try to have in next week's I-build (which means it > needs to be in Sunday's Nightly, IMHO. Now you let me know if that is > unrealistic. :) Sounds perfect to me :) I had the same thing in mind too...
(In reply to Arun Thondapu from comment #46) > > I suggest to tentatively try to have in next week's I-build (which means it > > needs to be in Sunday's Nightly, IMHO. Now you let me know if that is > > unrealistic. :) > > Sounds perfect to me :) I had the same thing in mind too... I have not had time to look at this yet. And, would not really be able to do a "test build" or anything until Monday afternoon, which is getting sort of late for Tuesday's I-build (especially given time zone differences!) To me, Wednesday morning would be the ideal time to "test", but I am glad to squeeze it in any other time according to your priorities. I just first want to make sure our N-builds (and web pages) are working again (Bug 490973) and want to make sure the I-build goes ok Tuesday.
I have finally looked more at this, locally. Findings: 1. I could add the triplet to our "target configuration" and, changing nothing else, it did not cause an overall build failure. The Platform and SDK "product creation" part of the build failed, but not an overall failure. So, I went ahead and added it, in case that helps anyone today. We can alway revert if it "gets in the way". http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=994acb6c24890b79deda03164ee800ffd6acba85 2. I added the "binary" module to the framework pom, locally, and tried to add to the feature, but then discovered (on immediate failure) that there appears to be no actual "fragment" that makes use of that binary. I am pretty sure I am "up to date". It that missing? Is there a fragment that needs to be checked in? And added to a pom? = = = = = = I will be offline soon for yet another dentist appointment, but could try a test build this afternoon (around 2 PM Eastern) if anyone thinks we will be ready for that. Otherwise, I will look closer at my local tests this afternoon, so see if I need to revert that change to the parent pom before the "nightly". = = = = = = = Advise welcome.
(In reply to David Williams from comment #48) > 2. I added the "binary" module to the framework pom, locally, and tried to > add to the feature, but then discovered (on immediate failure) that there > appears to be no actual "fragment" that makes use of that binary. I am > pretty sure I am "up to date". It that missing? Is there a fragment that > needs to be checked in? And added to a pom? Which fragment did it complain about exactly? Launcher or SWT? The launcher fragment was added via bug 429335 but had to be reverted due to a build failure. I can push the launcher fragment once again and also the SWT fragment along with the built binaries and you should probably try a local test build after that. I will update once I'm done with pushing the changes (having some weird git issues right now that should hopefully get resolved soon).
(In reply to Arun Thondapu from comment #49) > (In reply to David Williams from comment #48) > > 2. I added the "binary" module to the framework pom, locally, and tried to > > add to the feature, but then discovered (on immediate failure) that there > > appears to be no actual "fragment" that makes use of that binary. I am > > pretty sure I am "up to date". It that missing? Is there a fragment that > > needs to be checked in? And added to a pom? > > Which fragment did it complain about exactly? Launcher or SWT? The launcher > fragment was added via bug 429335 but had to be reverted due to a build > failure. I can push the launcher fragment once again and also the SWT > fragment along with the built binaries and you should probably try a local > test build after that. I will update once I'm done with pushing the changes > (having some weird git issues right now that should hopefully get resolved > soon). Launcher. I see, looking at bug 429335 there were script changes, etc. Perhaps that is what I was missing.
(In reply to David Williams from comment #50) > > Which fragment did it complain about exactly? Launcher or SWT? The launcher > > fragment was added via bug 429335 but had to be reverted due to a build > > failure. I can push the launcher fragment once again and also the SWT > > fragment along with the built binaries and you should probably try a local > > test build after that. I will update once I'm done with pushing the changes > > (having some weird git issues right now that should hopefully get resolved > > soon). > > Launcher. I see, looking at bug 429335 there were script changes, etc. > Perhaps that is what I was missing. Yes, that should be the case. I haven't been able to resolve my issues with git yet, so haven't pushed either launcher or SWT fragments to git, I'll take a look again tomorrow, can we try the test builds tomorrow? Hopefully, you won't have to revert any of your changes for the N-build meanwhile...
(In reply to Arun Thondapu from comment #51) > Hopefully, you won't have to revert any of your changes for the N-build > meanwhile... I did have to revert my commit from comment 48 (or else none of the Platform or SDK products were "built". But I did confirm that using one of the patches in bug 429335 I could successful do a local build. (That is, no failures, and all products built ... not sure it really build "Solaris 64" products, since I didn't have the binaries mentioned in bug 429335. But assume that's a minor detail :) > can we try the test builds tomorrow? Yep, on Friday?. There will be a few hours around noon I will be offline, but otherwise, I should be around.
I have finally resolved the weird git and network issues I was facing and have committed the launcher as well as SWT fragments and binaries for Solaris x86 64-bit. David, can you please try a local test build with your releng changes and see if there are any issues? If we're lucky, we could probably look forward to an N-build that can be smoke tested but if there are any issues, I'll only be able to check for updates tomorrow morning my time (which would be late evening or night your time). Thanks!
(In reply to Arun Thondapu from comment #53) > I have finally resolved the weird git and network issues I was facing and > have committed the launcher as well as SWT fragments and binaries for > Solaris x86 64-bit. > > David, can you please try a local test build with your releng changes and > see if there are any issues? If we're lucky, we could probably look forward > to an N-build that can be smoke tested but if there are any issues, I'll > only be able to check for updates tomorrow morning my time (which would be > late evening or night your time). Thanks! I did not see this in time for a test build ... before the Friday 8 PM nightly. I am not sure I did the right thing ... I committed the triplet to master, but not positive you committed the launcher to the launcher feature. Guess we'll find out soon. :)
Success! Well, at least, something was built. I've no idea if it works. :) This new build won't be "published" to downloads server yet. I'll need to add a few lines to scripts and data files to collect and display it, but if you want to get this first one directly from the build server, it is is under http://build.eclipse.org/eclipse/builds/4N/gitCache/eclipse.platform.releng.aggregator/eclipse.platform.releng.tychoeclipsebuilder/sdk/target/products/
Starting with today's N-build (Saturday, 4/9) the Solaris x86_64 artifacts will appear on the usual download page. And, for now, I have just commented out the 32 bit Sparc "display". (We still build them, I just commented out the display code.) Once we have 64-bit versions, I'll modify them as needed and uncomment them.
(In reply to David Williams from comment #56) > Starting with today's N-build (Saturday, 4/9) the Solaris x86_64 artifacts > will appear on the usual download page. > > And, for now, I have just commented out the 32 bit Sparc "display". (We > still build them, I just commented out the display code.) Once we have > 64-bit versions, I'll modify them as needed and uncomment them. When is the "64-bit Sparc" version to be ready? Tomorrow is next to the last I-build before "M7 stabilization week".
(In reply to David Williams from comment #57) > (In reply to David Williams from comment #56) > > Starting with today's N-build (Saturday, 4/9) the Solaris x86_64 artifacts > > will appear on the usual download page. > > > > And, for now, I have just commented out the 32 bit Sparc "display". (We > > still build them, I just commented out the display code.) Once we have > > 64-bit versions, I'll modify them as needed and uncomment them. > > When is the "64-bit Sparc" version to be ready? Tomorrow is next to the last > I-build before "M7 stabilization week". Will take another day or two as per my current estimates... the regular SPARC machine we use for our builds has been down for weeks now and we've just found an alternative which needs a fair bit of setting up before it is ready to be used for builds. Also, I'm still in the process of testing/verifying the x86 64-bit builds we now have.
Ok, thanks for the status. Since a new bug was open for the SPARC counterpart (bug 491517) I believe the "releng" part of this bug is nearly done. I think the only thing missing it to remove the "32-bit" parts. I assume there is no reason to leave them in? I will try on a local build first, but think to remove them is mostly to remove the triplets from the platform-target-configuration. <environment> <os>solaris</os> <ws>gtk</ws> <arch>sparc</arch> </environment> <environment> <os>solaris</os> <ws>gtk</ws> <arch>x86</arch> </environment> May have to coordinate with changes to with "launcher feature", or something. Should know late this evening. :)
(In reply to David Williams from comment #59) > Should know late this evening. :) Turned out to be more complicated than I thought. To "remove from build", besides the parent pom, there are 3 other places (features) to change at the same time. The first two in the following list I could do, but would have to be coordinated with the last two in UI, and Equinox. (And, BTW, when I say "remove from build" I mean to stop producing them as output of the build -- there would still be "cleanup" to do, to remove modules, etc., but once "removed from build", the rest could be done whenever, without affecting anything else.) I would propose we do this soon, such as "today", if someone from Equinox and UI is able and willing. Say ... 3 PM Eastern? (That'd give me time for test build before N-build, to be sure I didn't overlook something.) I am of course open to other times. Could even wait until Sparc 64 was ready, but to me, easier and safer to make changes "a little at a time"? eclipse.platform.releng.aggregator.patch == parent pom remove 2 triplets form execution targets eclipse.platform.releng.patch == platform-feature removes org.eclipse.core.filesystem.solaris.sparc from platform feature. eclipse.platform.ui.patch == org.eclipse.e4.rcp removes launchers from e4.rcp feature rt.equinox.framework.patch == org.eclipse.equinox.executable removes launchers from executable feature I will attach patches here. I don't think Gerrit changes help much, since each is small, and the Gerrit-Hudson builds would not work anyway since all of these need to be coordinated and built at once.
Created attachment 260962 [details] To remove from org.eclipse.equinox.executable
Created attachment 260963 [details] to remove from org.eclipse.e4.rcp feature
Created attachment 260964 [details] to remove native filesystem fragment from platform feature
Created attachment 260965 [details] remove from parent pom
New Gerrit change created: https://git.eclipse.org/r/70703
Gerrit change https://git.eclipse.org/r/70703 was merged to [master]. Commit: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=1d989716b4f7b6da00b68ea0dadf54c4f1e34a38
I committed the Equinox patch and I updated the e4.rcp feature with: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=2c7fce167b2d949d3da1ea6c6b1160ba139c4c2b Note that the original patch added the org.eclipse.swt.gtk.solaris.x86_64 fragment. I also added the org.eclipse.equinox.launcher.gtk.solaris.x86_64 fragment
Thanks, Tom, especially for correcting my mistakes. Just to document it here, my local test build completed fine ... and the solaris 64-bit Platform and SDK seem closer in size to the others :) A few bits of cleanup to do on the web page and I'll be done.
No web cleanup needed after all. I noticed the 32-bit jars still in downloads area, but we don't display them, and the way we copy them is very generic, simply pushd "$SWT_BUNDLES_DIR" cp */target/*.zip "$BUILD_DIR" So that will just require SWT to clean up their build and modules. The releng commponent won't need to be involved. So, now for the 64-bit Sparc platform we'll use bug 491517. Thanks again, all.
