search

TheAssassin / AppImageLauncher

Helper application for Linux distributions serving as a kind of "entry point" for running and integrating AppImages
https://assassinate-you.net/tags/appimagelauncher/
MIT License
5.54k stars 264 forks source link

Build and provide ARM binaries #293

Closed cityadpro closed 4 years ago

cityadpro commented 4 years ago

I'm developing an Electron app that I'd like to run on a Raspberry Pi 4B using latest Raspbian Buster. I'm using electron-builder package to create the AppImage for my Electron App, and since electron-builder version 21 the recommended way to integrate the AppImage to Desktop is AppImage Launcher. But there isn't any already built version of AppImage Launcher for Raspbian and I also cannot find any instructions on how to build it.

Is there anyone here that knows how to build and install AppImage Launcher on Raspbian Buster?

Thank you!

TheAssassin commented 4 years ago

You should be able to build just fine on Raspbian. This project is a regular CMake one. There's tons of guides out there, e.g., https://stackoverflow.com/a/7859663.

I've created a PR (#295) that is hopefully going to deliver official ARM64 binaries which should work on a RasPi like yours. Also it will make sure the project is buildable on such devices. I hardly ever test that manually.

cityadpro commented 4 years ago

Hello @TheAssassin ,

thank you for your fast answer.

I've done some tests using AppImage Launcher and running my Electron app on a Linux x86_64 computer and it seems that electron-updater and AppImage Launcher are not compatible at the moment, thus the Electron app is not able to auto update itself if using AppImage Launcher.

So at this moment, I'll not use AppImage Launcher until both can work together.

Thank you for your time!

TheAssassin commented 4 years ago

That's new to me. I have no problems using Electron based apps on my computer. But it's up to you to decide whether to use AppImageLauncher. Please feel free to open new issues if you find other problems

cityadpro commented 4 years ago

I don't think it is a problem with Electron or AppImageLauncher, but a problem with electron-builder and the way it handles auto updates through electron-updater package. I can also use AppImageLauncher without any problem with my Electron app, but when there's a new version to update it fails. This issue has already been detected and it doesn't seem that there's any move on it....

Finn0811 commented 4 years ago

Is the most recent "appimagelauncher_2.1.0-travis918.380cee8.bionic_arm64.deb" build the right one? I can't really install it on my raspberry pi 4.


dpkg: error processing archive /home/pi/Downloads/appimagelauncher_2.1.0-travis918.380cee8.bionic_arm64.deb (--install):
 package architecture (arm64) does not match system (armhf)
Errors were encountered while processing:
 /home/pi/Downloads/appimagelauncher_2.1.0-travis918.380cee8.bionic_arm64.deb```
TheAssassin commented 4 years ago

Oh, I was thinking the ARM64 stuff was enabled by default, but I just looked it up and that seems to be wrong. Raspbian at least still provide 32-bit images, probably to ensure compatibility on all devices so first-time users don't have to choose.

There are already available 64-bit images like Manjaro or Gentoo. On Raspbian you can get a 64-bit kernel, but I'm not sure if that allows for running ARM64 packages. I have doubts, but I try to find my RasPi 4 and try it out.

So, sorry for false advertising earlier.

References:

TheAssassin commented 4 years ago

I've built AppImageLauncher on a Raspberry Pi in the meanwhile just fine. On Travis there's some weird errors as of yet, I'll have to check what's going on.

But the released, official ARM64 binaries work just fine on a Pinebook (first gen) that I had on hand with the latest KDE neon image. I tested all features. There's some minor UI issues in the settings dialog (broken symbols), but that's to be expected in KDE.

I tried against some random ARM AppImage I found (fre:ac). There's a linking issue I found in our runtime, I'll have to check whether that needs to be fixed upstream in AppImageKit (links to libz.so instead of libz.so.1, but the former is only a symlink that is installed by the zlib1g-dev package which is not installed by default).

TheAssassin commented 4 years ago

We're building armhf binaries now, which should work on a recent Raspberry Pi image. I haven't tested that yet, as all my RasPis are still running on some older Debian, but I intend to try it on my RasPi 4 later. If they work, they'll be part of the next release.

Finn0811 commented 4 years ago

Awesome, thanks! I'll try asap and let you know how it works.

TheAssassin commented 4 years ago

Binaries work fine after a reboot. And I have an idea how to fix #286. Going to prepare the new release. Closing this issue as resolved.