MacOS M1 ARM support

[MattElek]

Is your feature request related to a problem? Please describe.
Currently, the Arduino IDE is only built for MacOS x86, and not MacOS M1 ARM. It is however built for ARM32 and ARM64 Linux.

Describe the solution you'd like
A build of the Arduino IDE for ARM64.

Describe alternatives you've considered
Rosetta 2 x86 translation works as expected, but it's not native.

Additional context
Pyserial seems to have already ironed out most issues on ARM. Additionally, there are already ARM64 Arduino ports for Linux.

[per1234]

It is however built for ARM32 and ARM64 Linux.

There are no official ARM Linux builds of Arduino IDE 2.x. Only the classic Arduino IDE is built for these host architectures: #107

[ubidefeo]

@MattElek
I have tried to build on M1 but some dependencies break, this is why we can't release for M1 Native yet.
The IDE performs very well on M1 using Rosetta 2, and we'll keep trying to build for M1 in the future, but dependencies and Electron related stuff is a stopper.
We don't use PySerial at all, because the Serial Monitor services are handled through the CLI behind the scenes

[SConaway]

Hey there, I'm wondering what the current roadblocks are...is it upstream stuff with Theia? If there's any work that's been done, I can try to continue off of that.

[fstasi]

Hi @SConaway, the current roadblocks are related to the theia version, that relies on node 14 and an outdated version of Electron.

Luckily, we have a PR in the making, that updates both of them and could enable the M1 native build.
At the moment I can't tell you yet if that PR is enough or if some additional tweaks are needed.

If you want to give us a feedback/help, I'd checkout the PR, then - on an M1 mac - run these commands

yarn --ignore-engines
yarn rebuild:browser
yarn rebuild:electron

If you can post the output that would be a great starting point for us to assess what is the updated state of the build

[PaulStoffregen]

The platform index specification has only 6 architecture names defined.

ARM Linux 32-bit (arm-linux-gnueabihf),
ARM Linux 64-bit (aarch64-linux-gnu),
macOS 64-bit (x86_64-apple-darwin14),
Windows (i686-mingw32),
Linux 32-bit (i686-linux-gnu),
Linux 64-bit (x86_64-linux-gnu)

Even if the IDE were built native for M1, the tools it runs to actually compile & upload code do not seem to have any way to support M1 until this is updated.

[per1234]

has only 6 architecture names defined.

That is only the list of host values used in the example package index above that statement:

In the example above avr-gcc comes with builds for

The full list is described by this algorithm:

https://github.com/arduino/arduino-cli/blob/10107d2407c2d9997310fc2e0f22dfd15d48e9a8/arduino/cores/tools.go#L126-L195

So the packages[*].tools[*].systems[*].host value for a macOS ARM native build of a tool would be something like arm64-apple-darwin11, but note this part:
https://github.com/arduino/arduino-cli/blob/10107d2407c2d9997310fc2e0f22dfd15d48e9a8/arduino/cores/tools.go#L185-L191

case "darwin,arm64":
	// Compatibility guaranteed through Rosetta emulation
	if regexpMac64.MatchString(f.OS) {
		// Prefer amd64 version if available
		return true, 20
	}
	return regexpMac32.MatchString(f.OS), 10

I had aspirations of providing comprehensive documentation for the supported packages[*].tools[*].systems[*].host values in the Package Index Specification, but never figured out how to go about it.

[SConaway]

Hi @SConaway, the current roadblocks are related to the theia version, that relies on node 14 and an outdated version of Electron.

Luckily, we have a PR in the making, that updates both of them and could enable the M1 native build. At the moment I can't tell you yet if that PR is enough or if some additional tweaks are needed.

If you want to give us a feedback/help, I'd checkout the PR, then - on an M1 mac - run these commands

yarn --ignore-engines
yarn rebuild:browser
yarn rebuild:electron

If you can post the output that would be a great starting point for us to assess what is the updated state of the build

Hey @fstasi, wasn't sure where to reply with logs.

Everything went fine until the actual yarn start running on node 14:

$ yarn start
yarn run v1.22.17
$ yarn --cwd ./electron-app start
$ theia start --plugins=local-dir:../plugins
dyld[4888]: Library not loaded: @rpath/libffmpeg.dylib
  Referenced from: /Users/steven/arduino-ide/node_modules/electron/dist/Electron.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework
  Reason: tried: '/Users/steven/arduino-ide/node_modules/electron/dist/Electron.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Libraries/libffmpeg.dylib' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64e')), '/Users/steven/arduino-ide/node_modules/electron/dist/Electron.app/Contents/MacOS/../Frameworks/libffmpeg.dylib' (no such file), '/Users/steven/arduino-ide/node_modules/electron/dist/Electron.app/Contents/MacOS/../Frameworks/libffmpeg.dylib' (no such file), '/usr/local/lib/libffmpeg.dylib' (no such file), '/usr/lib/libffmpeg.dylib' (no such file)
/Users/steven/arduino-ide/node_modules/electron/dist/Electron.app/Contents/MacOS/Electron exited with signal SIGABRT
✨  Done in 0.76s.

It's an issue in the eclipse-theia/theia repo's example, so I will look into it there.

[SConaway]

So, I am looking into things and it seems that the issue is the fact that theia wants node v14 to be used. Because of this, node-gyp doesn't build for arm64e but x86_64. using node v16 solves the issue!

[owiofwm2i]

so can you release your compiled version?

[SConaway]

so can you release your compiled version?

no, I can't release things for arduino...

[owiofwm2i]

just a download link for your compiled version

[fstasi]

@SConaway if you found a workaround for node-gyp compiling for x86_64 I'll create an official (signed) release and upload it.

[SConaway]

@SConaway if you found a workaround for node-gyp compiling for x86_64 I'll create an official (signed) release and upload it.

@fstasi, if there's a way to build the project using node v16, the issue should be solved.

[fstasi]

@SConaway if you found a workaround for node-gyp compiling for x86_64 I'll create an official (signed) release and upload it.

@fstasi, if there's a way to build the project using node v16, the issue should be solved.

@SConaway you can build the project with node v16 by using node 16 on your machine and then run yarn with the --ignore-engines flag. Sadly, this did not fix the issue for me, but please give it a try

[per1234]

Closing as duplicate of #408

The lack of support for building the IDE on (as opposed to distributing builds for) Apple M1/M2 machines is tracked here: #933