Community
Participate
Working Groups
This is the top level bug to track SWT support for Macs with Apple silicon. According to https://www.apple.com/newsroom/2020/06/apple-announces-mac-transition-to-apple-silicon/ they will be available by this year end. Relevant links with more details: https://developer.apple.com/documentation/apple_silicon https://developer.apple.com/documentation/xcode/porting_your_macos_apps_to_apple_silicon From https://developer.apple.com/documentation/xcode/building_a_universal_macos_binary: "Native apps run more efficiently than translated apps because the compiler is able to optimize your code for the target architecture. An app that supports only the x86_64 architecture must run under Rosetta translation on Apple silicon. A universal binary runs natively on both Apple silicon and Intel-based Mac computers, because it contains executable code for both architectures." So, the x86_64 libraries will mostly work on Apple silicon initially. But, using universal binaries will be more efficient. The SWT libraries have to be compiled as universal binaries for arm64 architecture using XCode 12.
I think it would be a significant win if we could get a Developer Transition Kit to work on the universal binary, so it's cool that Apple is showing interest in Eclipse.
I checked the Universal App Quick Start Program for the DTK - https://developer.apple.com/programs/universal/ From the link: "As part of the program, you’ll have limited access to a Developer Transition Kit (DTK), which will be shipped to you, for developing and testing your Universal apps. The DTK is owned by Apple and must be returned." Under Eligibility, I see that currently India is not a eligible region.
We have engaged with Apple to try and obtain access via our current cloud based Mac provider, which will hopefully allow us to simply add it as another build agent. Depending on how that goes, we may have to try and get actual silicon. -M.
I'll add the DTK as an headless agent by the end of the week.
What is the current plan, to build separate binaries, or to make the binaries multiplatform (AArch64 and X86_64)?
(In reply to Mikaël Barbero from comment #4) > I'll add the DTK as an headless agent by the end of the week. Unfortunately, I've had connectivity issue with the DTK. I've engaged with the cloud provider. I'll try again early next week.
(In reply to Mikaël Barbero from comment #6) > (In reply to Mikaël Barbero from comment #4) > > I'll add the DTK as an headless agent by the end of the week. > > Unfortunately, I've had connectivity issue with the DTK. I've engaged with > the cloud provider. I'll try again early next week. Is it working in the meantime?
No, sorry, I did not get the time to work on it yet.
*** Bug 568976 has been marked as a duplicate of this bug. ***
I got an update from our cloud provider earlier this morning. I'll try again setting this up today.
No luck so far. I've reported the issue back again to cloud provider.
Hi Mikael, any updates on this?
DTK is now connected to Jenkins' releng: https://ci.eclipse.org/releng/computer/6m8ka-macos11-a12z/ You tie jobs to it via the labels: apple-silicon macos-11 macos-dtk
(In reply to Mikaël Barbero from comment #13) > DTK is now connected to Jenkins' releng: > https://ci.eclipse.org/releng/computer/6m8ka-macos11-a12z/ > > You tie jobs to it via the labels: > apple-silicon > macos-11 > macos-dtk Thank you Mikael! Is there a way to access the UI?
(In reply to Lakshmi P Shanmugam from comment #14) > Thank you Mikael! > Is there a way to access the UI? No, it's for headless build only.
With rosetta translator one cannot mix arm 64 and x86_64 modules(see: https://developer.apple.com/documentation/apple_silicon/about_the_rosetta_translation_environment?language=objc). To run arm64 port for Mac we will need JVM to support arm64(see: https://openjdk.java.net/jeps/391) With JEP 391 pending this support may get delayed.
(In reply to Sravan Kumar Lakkimsetti from comment #16) > With rosetta translator one cannot mix arm 64 and x86_64 modules(see: > https://developer.apple.com/documentation/apple_silicon/ > about_the_rosetta_translation_environment?language=objc). > > To run arm64 port for Mac we will need JVM to support arm64(see: > https://openjdk.java.net/jeps/391) > > With JEP 391 pending this support may get delayed. Eclipse/SWT support for Mac arm64 is not dependent on JEP 391. It's possible to run a macOS/x64 build of the JDK on arm64 Mac, the JEP also states that.
(In reply to Sravan Kumar Lakkimsetti from comment #16) > With rosetta translator one cannot mix arm 64 and x86_64 modules(see: > https://developer.apple.com/documentation/apple_silicon/ > about_the_rosetta_translation_environment?language=objc). > > To run arm64 port for Mac we will need JVM to support arm64(see: > https://openjdk.java.net/jeps/391) > > With JEP 391 pending this support may get delayed. Sorry if I am jumping into an internal conversation. However we are keen to have the Eclipse SWT support on macOS arm64 that's why feel it necessary. And hopefully it helps. Azul has provided Zulu community builds of OpenJDK for macOS arm64 (https://www.azul.com/downloads/zulu-community/?os=macos&architecture=arm-64-bit) which you may want to check out.
(In reply to Lakshmi P Shanmugam from comment #17) > (In reply to Sravan Kumar Lakkimsetti from comment #16) > > With rosetta translator one cannot mix arm 64 and x86_64 modules(see: > > https://developer.apple.com/documentation/apple_silicon/ > > about_the_rosetta_translation_environment?language=objc). > > > > To run arm64 port for Mac we will need JVM to support arm64(see: > > https://openjdk.java.net/jeps/391) > > > > With JEP 391 pending this support may get delayed. > > Eclipse/SWT support for Mac arm64 is not dependent on JEP 391. It's possible > to run a macOS/x64 build of the JDK on arm64 Mac, the JEP also states that. From https://developer.apple.com/documentation/apple_silicon/about_the_rosetta_translation_environment?language=objc ------ Important The system prevents you from mixing arm64 code and x86_64 code in the same process. Rosetta translation applies to an entire process, including all code modules that the process loads dynamically. ------ This rules out usage of arm64 based swt native libraries on Rosetta translated x86_64 JVM. In JEP 391 there are changes to to support new Application Binary Interface and changes to memory access. Without those changes I have my doubts in claiming support on MacOS Arm64 port.
Created attachment 285574 [details] I20210214-0600 build log on m1 mac
(In reply to Janboe Ye from comment #20) > Created attachment 285574 [details] > I20210214-0600 build log on m1 mac it built failure. Please help to check how to fix it. Thanks
(In reply to Sravan Kumar Lakkimsetti from comment #19) > (In reply to Lakshmi P Shanmugam from comment #17) > > (In reply to Sravan Kumar Lakkimsetti from comment #16) > > > With rosetta translator one cannot mix arm 64 and x86_64 modules(see: > > > https://developer.apple.com/documentation/apple_silicon/ > > > about_the_rosetta_translation_environment?language=objc). > > > > > > To run arm64 port for Mac we will need JVM to support arm64(see: > > > https://openjdk.java.net/jeps/391) > > > > > > With JEP 391 pending this support may get delayed. > > > > Eclipse/SWT support for Mac arm64 is not dependent on JEP 391. It's possible > > to run a macOS/x64 build of the JDK on arm64 Mac, the JEP also states that. > > From > https://developer.apple.com/documentation/apple_silicon/ > about_the_rosetta_translation_environment?language=objc > ------ > Important > > The system prevents you from mixing arm64 code and x86_64 code in the same > process. Rosetta translation applies to an entire process, including all > code modules that the process loads dynamically. > ------ > > This rules out usage of arm64 based swt native libraries on Rosetta > translated x86_64 JVM. > > In JEP 391 there are changes to to support new Application Binary Interface > and changes to memory access. Without those changes I have my doubts in > claiming support on MacOS Arm64 port. I don't believe that JEP 391 is a precondition for supporting Eclipse/SWT natively on M1 Apple machines. You point out that Rosetta does not allow mixing x86_64 and arm64 code, and that's true but not relevant. If the JRE is arm64 then Rosetta is not needed. We simply require that all binaries (including the SWT dylibs) to be compiled for arm64. I have been working on a non-Eclipse Java application that includes native libraries. We just got it fully working on Azul's Zulu Java 11 build for arm64 along with arm64 dylibs for our native components. Eclipse may or may not be able to ship Azul's arm64 builds with Eclipse; that's a legal question that I'm not qualified to comment on. But shipping Eclipse without a Java runtime was the standard practice for over a decade. RCP application authors can still choose whether to ship a JRE with their app. We really just need the arm64 dylibs for SWT.
(In reply to Neil Bartlett from comment #22) > We really just need the arm64 dylibs for SWT. Please try using https://download.eclipse.org/eclipse/downloads/drops4/I20210226-0220/download.php?dropFile=swt-I20210226-0220-cocoa-macosx-arm64.zip. We have been building arm64 dylibs from quite sometime.
(In reply to Sravan Kumar Lakkimsetti from comment #23) > We have been building arm64 dylibs from quite sometime. Thanks I wasn't aware! This could definitely help me as an RCP author. With consumer M1 machines now available, I have customers asking when I will release a native edition :-/
(In reply to Neil Bartlett from comment #24) > (In reply to Sravan Kumar Lakkimsetti from comment #23) > > > We have been building arm64 dylibs from quite sometime. > > Thanks I wasn't aware! This could definitely help me as an RCP author. With > consumer M1 machines now available, I have customers asking when I will > release a native edition :-/ For RCP to work we need bug 570540 to get fixed. We will start on that once the 4.19 RC2 work is done by March 5.
New Gerrit change created: https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/176934
Gerrit change https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/176934 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=2cc5195513278a34f74d05d82af73ed7f2de2c2c
The SWT libraries for Mac Arm64 are available for testing - https://download.eclipse.org/eclipse/downloads/drops4/S-4.19M3-202102171800/#SWT It's marked as Early Access due to limited testing. Request the community to test and report any issues.
So do I understand it correctly, that we would have to create different .app structures for x86_64 Macs and for M1 Macs? Or can both be unified in one bundle working on both platforms?
(In reply to Thomas Singer from comment #29) > So do I understand it correctly, that we would have to create different .app > structures for x86_64 Macs and for M1 Macs? Or can both be unified in one > bundle working on both platforms? At the moment it looks like there will have to be separate .app releases for the two architectures, principally because the JRE is a set of single-architecture binaries. To create a universal app we would need both SWT and the JVM to be released as universal/fat binaries. I believe it may be possible to reconstruct a universal binary from the corresponding x86_64 and arm64 pieces using the `lipo` tool. I'm going to be experimenting with that next week. But that's unlikely to be a production-ready solution.
> there will have to be separate .app releases for the two architectures Given that we already distribute separate Intel/Arm binaries for GNU/Linux, I don't think that doing it for macOS too would be a problem.
** Heads up ** Until now, the Eclipse Foundation has been benefiting from one DTK from Apple hosted at MacStadium. Apple is calling back the DTK they've been providing and we just received an email from MacStadium that they will pull off our instance this weekend. It means that the Apple Silicon agent won't be available anymore. In order to get another Apple Silicon agent, the project has 2 solutions: * The Eclipse project finds an EF member sponsoring a dedicated macos agent, and the Foundation will then setup a new machine like we did with the DTK (see https://wiki.eclipse.org/CBI#Additional_Resource_Packs for sponsoring details), * The Eclipse project finds a company or an individual with an Apple Silicon machine connected to the internet and willing to connect it to the Jenkins controller https://ci.eclipse.org/releng for the project to use as an agent (see https://wiki.eclipse.org/Jenkins#Can_I_add_a_dedicated_agent_to_my_Jenkins_instance.3F for details about how such a dedicated agent is connected to the controller).
(In reply to Mikaël Barbero from comment #32) > ** Heads up ** > > Until now, the Eclipse Foundation has been benefiting from one DTK from > Apple hosted at MacStadium. Apple is calling back the DTK they've been > providing and we just received an email from MacStadium that they will pull > off our instance this weekend. It means that the Apple Silicon agent won't > be available anymore. > > In order to get another Apple Silicon agent, the project has 2 solutions: > > * The Eclipse project finds an EF member sponsoring a dedicated macos agent, > and the Foundation will then setup a new machine like we did with the DTK > (see https://wiki.eclipse.org/CBI#Additional_Resource_Packs for sponsoring > details), > > * The Eclipse project finds a company or an individual with an Apple Silicon > machine connected to the internet and willing to connect it to the Jenkins > controller https://ci.eclipse.org/releng for the project to use as an agent > (see > https://wiki.eclipse.org/ > Jenkins#Can_I_add_a_dedicated_agent_to_my_Jenkins_instance.3F for details > about how such a dedicated agent is connected to the controller). Thank you for the heads up. Before the machine is pulled out can you please setup latest version of Xcode (we need atleast 12) on https://ci.eclipse.org/releng/computer/b9h15-macos10.12/ other wise we have pull out mac arm64 builds.
(In reply to Sravan Kumar Lakkimsetti from comment #33) > Thank you for the heads up. Before the machine is pulled out can you please > setup latest version of Xcode (we need atleast 12) on > https://ci.eclipse.org/releng/computer/b9h15-macos10.12/ other wise we have > pull out mac arm64 builds. Xcode 12 requires macOS 10.15.4. The agent is running macOS 10.12.6. Should I update it as well?
(In reply to Mikaël Barbero from comment #32) > ** Heads up ** > > Until now, the Eclipse Foundation has been benefiting from one DTK from > Apple hosted at MacStadium. Apple is calling back the DTK they've been > providing and we just received an email from MacStadium that they will pull > off our instance this weekend. It means that the Apple Silicon agent won't > be available anymore. > > In order to get another Apple Silicon agent, the project has 2 solutions: > > * The Eclipse project finds an EF member sponsoring a dedicated macos agent, > and the Foundation will then setup a new machine like we did with the DTK > (see https://wiki.eclipse.org/CBI#Additional_Resource_Packs for sponsoring > details), > > * The Eclipse project finds a company or an individual with an Apple Silicon > machine connected to the internet and willing to connect it to the Jenkins > controller https://ci.eclipse.org/releng for the project to use as an agent > (see > https://wiki.eclipse.org/ > Jenkins#Can_I_add_a_dedicated_agent_to_my_Jenkins_instance.3F for details > about how such a dedicated agent is connected to the controller). Sorry for the maybe stupid question: Does that mean we cannot create macOS 64bit builds / packages anymore?
(In reply to Mikaël Barbero from comment #34) > (In reply to Sravan Kumar Lakkimsetti from comment #33) > > Thank you for the heads up. Before the machine is pulled out can you please > > setup latest version of Xcode (we need atleast 12) on > > https://ci.eclipse.org/releng/computer/b9h15-macos10.12/ other wise we have > > pull out mac arm64 builds. > > Xcode 12 requires macOS 10.15.4. The agent is running macOS 10.12.6. Should > I update it as well? yes please
(In reply to Mikaël Barbero from comment #34) > (In reply to Sravan Kumar Lakkimsetti from comment #33) > > Thank you for the heads up. Before the machine is pulled out can you please > > setup latest version of Xcode (we need atleast 12) on > > https://ci.eclipse.org/releng/computer/b9h15-macos10.12/ other wise we have > > pull out mac arm64 builds. > > Xcode 12 requires macOS 10.15.4. The agent is running macOS 10.12.6. Should > I update it as well? yes please go ahead with the update.
(In reply to Matthias Becker from comment #35) > (In reply to Mikaël Barbero from comment #32) > > ** Heads up ** > > > > Until now, the Eclipse Foundation has been benefiting from one DTK from > > Apple hosted at MacStadium. Apple is calling back the DTK they've been > > providing and we just received an email from MacStadium that they will pull > > off our instance this weekend. It means that the Apple Silicon agent won't > > be available anymore. > > > > In order to get another Apple Silicon agent, the project has 2 solutions: > > > > * The Eclipse project finds an EF member sponsoring a dedicated macos agent, > > and the Foundation will then setup a new machine like we did with the DTK > > (see https://wiki.eclipse.org/CBI#Additional_Resource_Packs for sponsoring > > details), > > > > * The Eclipse project finds a company or an individual with an Apple Silicon > > machine connected to the internet and willing to connect it to the Jenkins > > controller https://ci.eclipse.org/releng for the project to use as an agent > > (see > > https://wiki.eclipse.org/ > > Jenkins#Can_I_add_a_dedicated_agent_to_my_Jenkins_instance.3F for details > > about how such a dedicated agent is connected to the controller). > > Sorry for the maybe stupid question: > Does that mean we cannot create macOS 64bit builds / packages anymore? Its M1 processor builds that will get affected with this. We are trying to mitigate the problem by using cross compiler from Xcode 12.
(In reply to Mikaël Barbero from comment #34) > (In reply to Sravan Kumar Lakkimsetti from comment #33) > > Thank you for the heads up. Before the machine is pulled out can you please > > setup latest version of Xcode (we need atleast 12) on > > https://ci.eclipse.org/releng/computer/b9h15-macos10.12/ other wise we have > > pull out mac arm64 builds. > > Xcode 12 requires macOS 10.15.4. The agent is running macOS 10.12.6. Should > I update it as well? Opened Bug 572065 to install the required SDKs as well.
(In reply to Sravan Kumar Lakkimsetti from comment #38) > Its M1 processor builds that will get affected with this. We are trying to > mitigate the problem by using cross compiler from Xcode 12. So is this answer a yes or no?
(In reply to Matthias Becker from comment #40) > (In reply to Sravan Kumar Lakkimsetti from comment #38) > > Its M1 processor builds that will get affected with this. We are trying to > > mitigate the problem by using cross compiler from Xcode 12. > > So is this answer a yes or no? mac x86_64 will not get affected.
https://ci.eclipse.org/releng/computer/b9h15-macos10.12/ has been upgraded to macOS 10.15
I've remove the DTK agent from the agents list as it has been unplugged during the week end.
I tested the arm64 swt.jar a bit and finally was able to run eclipse full "apple" architecture with it. While using it for a while I noticed the images on SWT.PUSH buttons are not displayed correctly. Not sure if this is swt or the "hacked" eclipse integration. See screenshot attached. (eclipse-swt-aarch64.png)
Created attachment 286061 [details] eclipse-swt-aarch64.png
I want to correct myself, the icons seem to work but the text alignment is off.
Added a separate bug for the alignment issue, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=572696
(In reply to Holger Staudacher from comment #44) > I tested the arm64 swt.jar a bit and finally was able to run eclipse full > "apple" architecture with it. While using it for a while I noticed the > images on SWT.PUSH buttons are not displayed correctly. Not sure if this is > swt or the "hacked" eclipse integration. See screenshot attached. > (eclipse-swt-aarch64.png) Thanks for testing and the bug reports. I see this problem too, in Eclipse launched with the Java launcher (Bug 572115).
The Mac arm64 *Early Access* builds are now available for testing on the downloads page. The known issues are tracked by Bug 572797. Please try it out and report bugs and link to the root bug - Bug 572797.
(In reply to Lakshmi P Shanmugam from comment #50) > The Mac arm64 *Early Access* builds are now available for testing on the > downloads page. > The known issues are tracked by Bug 572797. Please try it out and report > bugs and link to the root bug - Bug 572797. https://download.eclipse.org/eclipse/downloads/drops4/I20210414-0330/
New Gerrit change created: https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/180122
Gerrit change https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/180122 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=f6085af49dec39f1513a1a59635cbd8629c2e143
Resolving the plan item. The Eclipse builds for Mac AArch64 are available on the downloads page - https://download.eclipse.org/eclipse/downloads/index.html The Eclipse Mac Arm64 builds are now called Mac AArch64 and uses osgi.arch=aarch64 (Bug 572799) Please note that a Mac AArch64 JVM is required to run Eclipse for Mac AArch64. The known issues are tracked by Bug 572797. Please report bugs and link to the root bug - Bug 572797.
Which is the right path for building the SWT jar for the M1 processor - eclipse.platform.swt.binaries\bundles\org.eclipse.swt.cocoa.macosx.arm64 or eclipse.platform.swt.binaries\bundles\org.eclipse.swt.cocoa.macosx.aarch64?
(In reply to Thomas Singer from comment #55) > Which is the right path for building the SWT jar for the M1 processor - > eclipse.platform.swt.binaries\bundles\org.eclipse.swt.cocoa.macosx.arm64 or > eclipse.platform.swt.binaries\bundles\org.eclipse.swt.cocoa.macosx.aarch64? eclipse.platform.swt.binaries\bundles\org.eclipse.swt.cocoa.macosx.aarch64 is the correct path. The org.eclipse.swt.cocoa.macosx.arm64 fragment was renamed to aarch64, but looks like the folder still exists, will delete it.
(In reply to Lakshmi P Shanmugam from comment #56) > The org.eclipse.swt.cocoa.macosx.arm64 fragment was renamed to aarch64, but > looks like the folder still exists, will delete it. Done via Bug 573631.
When will it be released?
(In reply to jeongi an from comment #58) > When will it be released? 4.20 will be released on June 16. The 4.20 RC1 builds are available for testing - https://download.eclipse.org/eclipse/downloads/drops4/S-4.20RC1-202105262310/
There are no macOS AArch64 build on https://www.eclipse.org/downloads/packages/ I also could not find Eclipse Installer for macOS AArch64. Could someone point me to the right downloads page?
Only Eclipse Platform project released Mac Arm64 this cycle. You can get it from https://download.eclipse.org/eclipse/downloads/drops4/R-4.20-202106111600/ and install the plugins you need on top of it.
Currently we have got new LTS Java 17 and we have bundle with native support for Apple Silicon -> JDK 17 (arm64) architecture Is there any possibility that Eclipse bundle will be released for this architecture? Because currently Eclipse bundle for macOS (x86_64) won't start with JDK 17 (arm64) Details described here: https://www.eclipse.org/forums/index.php/m/1844564/#msg_1844564
(In reply to Alexandr Bolbat from comment #62) Eclipse for ARM is available today, but only in "SDK" form, you can get it from https://download.eclipse.org/eclipse/downloads/drops4/R-4.21-202109060500/ and install the additional plug-ins you want. Please see Bug 575680 for the IDE packages feature request that will provide pre-bundled versions of the Eclipse IDE for Mac M1.
