Electron-builder: Build on an armv7l architecture ends up with "Cannot set machine from deb_arch 'armv7l'

[AntoineFootbar]

• Version: [email protected]

[email protected]

• Target: Linux (armv7l) for AppImage

Hello everyone,
I am trying to build my app with electron builder and publish it to my github repo, so I use the command electron-builder --linux --armv7l -p always but it ends with a "Cannot set machine from deb_arch armv7l". Then, my app cannot be published and the file "latest-linux-arm.yml" is not generated. Any advice ?
Thanks !

[TsPuujee]

yarn add electron-packager
add to package.json
scripts": {
"dist": electron-packager ./ MyApp --platform=linux --arch=armv7l
}
yarn dist

[njho]

Any solution?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[timfish]

It's still not possible to build deb or AppImage on armv7l

[develar]

@timfish Now you can build snap for arm (tested on Raspberry Pi Desktop) on any OS

Regarding deb.... Hmm... Please try 21.0.8 and report actual error for deb (if still actual).

To clear up — snap is the only format for Linux that recommended for all cases and fully supported on any OS and arch. I will never provide, build and test native deps for AppImage for ARM (and even for x64 it is not bullet proof and reliable, opposite to snap) because it is enormous amount of work. In case of snap, all this enormous amount of work is done by Canonical, and users of your app doesn't pay for this in terms of app size, because Canonical provides bases for core and gnome platforms for each arch (so, it is not part of your app, but automatically downloaded (if not yet) as part of snap installation).

[timfish]

Due to this issue, anybody targeting current Pi distros must use Electron v3 or older.

Does 21.0.8 still support building with Electron v3? I know Electron v2 support was dropped somewhere in 20.x.x.

The default and recommended electron-builder target for Linux has been AppImage for years. We have shipped to thousands of users as AppImage and we are very happy with the result so we cannot migrate x64 to snap any time soon.

For Pi, if our software is to end up in official repositories we still need to build deb so it looks like we'll have to do this manually.

[develar]

@timfish Thanks to Canonical, you can forget about glibc and other weird stuff. https://github.com/electron/electron/issues/16205 issue doesn't affect snap produced by electron-builder. I tested Electron 5 on PI.

Does 21.0.8 still support building with Electron v3

Yes, but as stated, forget about mentioned issue, it doesn't matter anymore for snap.

default and recommended electron-builder target for Linux has been AppImage for years

and it is still so. AppImage is not removed from default target, we are working closely with AppImage team and we do continue active development, see https://github.com/electron-userland/electron-builder/releases/tag/v21.0.1 about desktop integration. But I want just to make clear that you cannot expect that I will update ARM native deps (or x64) for free and without any request from some company (current set is developed by me and tested by pcloud company).

so it looks like we'll have to do this manually.

Please try 21.0.8 and report actual error. It will be fixed.

[develar]

so we cannot migrate x64 to snap any time soon

@timfish There is one simple solution, that will give you the same level of security/dependency independency for AppImage (glibc and so on), as for Snap — simply merge core/gnome-platform and electron-builder snap template into one layer and pack it as AppImage. If you don't want to migrate to snap but have dependency issues with AppImage and you don't want to spend hundreds of hours to test AppImage on various distro (as it was already performed by pcloud, but probably now a little bit outdated) — then it can be a solution. Price — increased size of app (for snap ~50 MB, for AppImage it will be ~200 or bigger (I didn't measure)). It can be done by request.

[timfish]

But I want just to make clear that you cannot expect that I will update ARM native deps (or x64) for free and without any request from some company

@develar I certainly don't expect you to do this for free!

Thanks for the tips, I'm trying 21.0.8 now and will report back.

[jtc42]

Just in case it helps at all, we're currently building a project for Raspberry Pi, both .deb and AppImage, using the electron-builder config:

extends: app/builder-config-base.yaml
electronVersion: 3.0.13
linux:
  target:
    - target: deb
      arch:
        - armv7l
    - target: appImage
      arch:
        - armv7l
  icon: app/icons/png/
  category: Science
deb:
  fpm: ['--architecture', 'armhf']

This has been working on a Ubuntu x64 machine, WSL on a Windows machine, and on our GitLab CI. Everything builds and runs just fine on Raspbian Stretch and Buster, tested on Pi 2, 3, and 4.

It looks like Raspbian Buster actually includes an updated glibc so it may even be that you can build with newer versions of Electron. I'll be trying that soon.

[develar]

fpm: ['--architecture', 'armhf']

Ouch, that's the trick, thanks a lot! So, as you have confirmed that it works, I will use this transformation of arch (armv7l -> armhf) not only for snap, but for all FPM-backed targets.

[timfish]

Oooohh, interesting! Is this with native node modules too?

As far as I've been able to work out, node-gyp does not support cross compilation so we're still building our native modules and packaging on the Pi.

[jtc42]

From Wikipedia:

In Debian GNU/Linux, and derivatives such as Ubuntu, armhf (ARM hard float) refers to the ARMv7 architecture including the additional VFP3-D16 floating-point hardware extension (and Thumb-2) above.

As far as I can tell, all this is config line is doing is changing the package metadata to identify as armhf instead of specifically armv7l. The Raspberry Pi defaults to identifying as armhf, so this lets the packages run on the Pi.

If your node modules will compile for armv7l, and you run the armhf package on an armv7l-compatible device, then I don't see why it wouldn't work.

[develar]

Is this with native node modules too?

No, this bloody situation when one arch is named differently for each tool (node, go, linux, package convention and so on) doesn't affect node modules because historically I did mistake and started to implement electron-builder in NodeJS instead of Go, so, node platform arch name is first in this name chain :)

node-gyp does not support cross compilation so we're still building our native modules and packaging on the Pi.

You just need to ask author of such module to use https://github.com/prebuild/prebuild If it is your own code, then yeach, no way (yes, soon free electron-build service will support ARM in addition to x64, but I am not going to support NodeJS native modules for security reasons, only platform packages for deb/snap/etc will be supported)).