Apple Silicon M1 support

Features
1

Hello, in what stage is development of Universal/Native M1 binary for Joplin?

3 Likes
2

Afaik none of the devs have a Mac with an M2 chip. This makes testing a bit complicated. I also do not know, if the gh build pipeline supports M1 yet.

I also don't know how the upstream support is for that. I know that electron-builder allows us to set the target for ARM64. Not sure what happens, if I run this on Intel though.

I'm against a universal binary and do hope that we don't go in this direction.

I think dedicated binaries for Intel and ARM are better. On the other side, why do you even need a native binary? Rosetta2 does a great job and I doubt there are any significant performance advantages at the moment (for an Electron app). I'm not saying this won't change in the future.

3

Thanks for the reply.

I'm too definitely for the separate dedicated binaries. Universal build just takes more space and "the other" binary is rather useless.

Rosetta2 is fine and in most cases there are no significant performace advantages, but there are still some difficulties or negatives in that.

For example higher energy and memory usage (which results in higher swap memory being written and eventually insane, almost damaging values are being written onto a SSD) has been reported on various forums when running multiple applications under rosetta2. I definitely see this phenomenon when running for example evernote+microsoft teams+fb messenger under rosetta2. Memory used is significantly (I'm talking in GBs) higher then let's say having open repository in VSCode+project in IntelliJ+Notion (all native solutions).

Another fact is, that if it is possible, there is no reason for me to just "settle" on emulated version and run it until I'm completely done with my macbook. It's the same as buying a pc, but running your apps in virtual machine 100 % of the time. If you pc is good, you still won't feel and significant performance disadvantages, but running it without emulation would still be better.

I may even try to compile it myself for M1 architecture if devs don't want to take this direction. I'm completely fine with that.

4

A user already did that. See here Running joplin on Apple silicon - #9 by bjbk

1 Like
5

Hi,If usefull, I have a M1 Mac, and I am ready to run tests on y machine once a M1 Joplin version is produced by a dev
Bruno

6

For that we have to upgrade Electron first.

1 Like
7

The app-desktop now builds on the M1. I am able to use this.

However, the app-cli does not. Are there any plans for getting this ported to the M1?

1 Like
8

Thanks for the info, could you tell us (even in a few words), the specials steps needed to do so?

9

I don't know much about the JS ecosystem, else I'd have led the fix.

From what I understand, from the little I've seen, it's not building on the M1.

One way to check this is to attempt starting the app-cli

╰─❯ npm install

postinstall
npm run bootstrap --no-ci && npm run build

bootstrap
lerna bootstrap --force-local --no-ci

lerna notice cli v3.22.1
lerna info versioning independent
lerna info Bootstrapping 15 packages
lerna info Installing external dependencies
lerna ERR! npm install exited 1 in '@joplin/plugin-repo-cli'
lerna ERR! npm install stderr:
npm ERR! cb() never called!

npm ERR! This is an error with npm itself. Please report this error at:
npm ERR! <https://github.com/npm/cli/issues>

lerna ERR! npm install exited 1 in '@joplin/plugin-repo-cli'
lerna WARN complete Waiting for 7 child processes to exit. CTRL-C to exit immediately.
npm ERR! code 1
npm ERR! path /Users/igbanam/projects/joplin
npm ERR! command failed
npm ERR! command sh -c npm run bootstrap --no-ci && npm run build

npm ERR! A complete log of this run can be found in:
npm ERR! /Users/igbanam/.npm/_logs/2021-05-21T15_57_59_145Z-debug.log
_p9k_cache_stat_get:9: too many open files in system: /dev/null
_p9k_glob:7: too many open files in system: /dev/null

10

This most likely means your ulimit for open files is set too low.

11

Remembering how NPM handles files, I thought this was an NPM-specific issue, so I tried using Yarn to install Joplin.

yarn global add joplin

This errors out when it tries to find the vips/vips.h file. This is needed by lovell/sharp for image manipulation. — seeing that this is a CLI app, I don't see why it needs image manipulation; but this is besides the point. — I installed libvips using Homebrew. After this, I could install Joplin CLI with Yarn.

1 Like
12

hey,
Is there an update on this topic?
Is the native support for m1 on the roadmap?
Thanks

2 Likes
13

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.