armv7 AppImage progress

• Jan 6, 2019 - 18:41

well I managed to buil Qt 5.12 on armv7 debian stretch (although ran into a hiccup with webengine I couldn't figure out...says it's an "internal compiler error, whatever that means" if anyone can maybe give me a tip: But anyway I am able to succesfully build musescore with webengine disabled and it seems to run fine, of course without the startcenter. So I'll try to update the AppImage script. Then the few users can run it on their Rpi 2 & 3 and their android tablets inside of a vnc or xserver program. Note: arch linux already does have 3.0 built in their distro for armv7 and aarch64, since arch linux is up-to-date with qt 5.12. But an AppImage will allow those arm users on debian stretch+ and ubuntu 16.04+ and other distros to use it too.

I don't know if it is worth to try to build on the ealier debian jessie (which is what the previous appimage was on) cause I might run into another error building Qt...and it is so hard to compile Qt anyway. Most of the small number of users who would be on arm I think will at least be running Raspian strech on their raspberries, or if running in their androids, will almost certainly use a debian or ubuntu os as new as stretch.

I'll first get the appimage built on my computer before trying to do it on Travis-CI. But one question I have is there any new way to collect the resulting build artificats off of travis-ci?


I might not bother doing the Travis-CI actually since I'm really the only tester on arm I think. So I'll just manually build AppImages for each new releases to upload (maybe to my github or wherever) for people to download.

Actually in the meantime I was trying during these last days of holiday to make a functioning AppImage type 2 for x86_34. At the moment I am at this point:…
it should build and upload the MuseScore 3-dev AppImage to my bintray account
I tried with the default updated and it was working, so I now tried to patch the version in MuseScore's source code and force pushed the commit.
I also wanted to try to see if the AppImageUploader was working on this build.
At the moment I used the update info automatically generated for bintray:…

I think the changes I made in my branch would break the AppImage generation for other architectures (but at the moment they were not working even in master branch), but I don't think my modifications are ready of course for merging, yet.
Maybe you could see if an AppImage version 2 could be done also for armhf. I see that AppImageKit is available also for that architecture, but maybe linuxdeployqt should be specifically compiled for that architecture. Actually, linuxdeploy (alterntive to linuxdeployqt if used with its qt plugin) comes with a plugin for experimentally including new system libraries for running softwares compiled with these new libraries on older systems.

By the way, the bintray uploading scripts at the moment present in MuseScore sources works, but only for AppImage type 1 (provided that it is enabled… and the file name does not contain strange characters such as brackets).


Do you still have an unanswered question? Please log in first to post your question.