Updated build for ARM?

• May 29, 2020 - 21:20
Reported version
3.3
Type
Functional
Frequency
Many
Severity
S5 - Suggestion
Reproducibility
Always
Status
GitHub issue
Regression
No
Workaround
Yes
Project
MuseScore

Does someone still build Musescore for ARM? I noticed the last edition available as an AppImage (or in my repository) is 2.0.3. It'd be great to see 3.x on there, but if that proves too difficult, even 2.3.2 would be an improvement!

Comments

• May 31, 2020 - 00:00

Which OS do you use to run MuseScore on your ARM device? I would suggest looking at packages from Debian project which builds software included to it for multiple architectures (including MuseScore), not sure whether they are possible to be installed on your system.

Reply

• Jun 1, 2020 - 21:46

Thanks for the reply, dmitrio95.

I'm trying to run this on Raspbian. Fortunately, I met Mirabilos on the Musescore IRC channel (#musescore on Freenode), who was able to help me by providing detailed instructions on how to add the Debian "backport" repositories, get the "musescore-common" dependencies, and install both 2.3.2 and 3.2.3, both of which now will launch (though there are numerous problems with the soundfont/synthesisizer/audio-export).

I still think it'd be great, however, to see an AppImage for 2.3.2 (or 3.x, or preferably both) if anyone is capable of making one. I realize that AppImage is not the "normal" Linux approach, but it'd sure help Linux newbies like myself.

Reply

• Jun 16, 2020 - 12:17

I installed ManjaroARM on my Pi4, and in their repository is Musescore 3.2. Therefore someone has compiled V3 for ARM.
But I do much prefer Raspberry Pi OS to ManjaroARM64

Reply

• Jun 19, 2020 - 10:01

Hi Musescore team, if ManjaroARM64 can have a distribution of V3, is it possible we have V3 for the rest of the ARM world too please ?
You are leaving behind a substantial number of musescore users. Eric Fontaine ( https://github.com/ericfont ) compiled 2.3.2 for us on his own I think, many SBC users and Raspberry Pi 4 users would be eternally grateful if you could make an ARM64 distribution available.
( Now the Pi4 has 64bit OS available, USB 3.0, dual band wifi, BT 5 & Gigabit ethernet & enough memory for almost anybody it is the most viable SBC on cost/performance and a LOT of people are now using it as their main desktop. )

Attachment Size
pi4IceTower.jpeg 5.63 KB

Reply

• Jun 19, 2020 - 13:26

Well, AppImages are usually compiled in the oldest possible OS distribution, so that they do not rely on modern libc libraries and can run in older systems.
A couple of years ago there was some effort to try to compile what was at the time the 3.0.x branch for ARM, see https://musescore.org/en/node/105901 but in the end I got discouraged and gave up because the resulting AppImage was not working and I could not really directly test it.
I think ericfontainejazz, as you wrote, has achieved some results in compiling ARM Qt 5 in the meantime, but I don't know how far he got in updating MuseScore build script.

Reply

• Jul 3, 2021 - 21:51

Just picked up an ARM-based Chromebook, and I am happy to report the arm64 AppImage works. So, would it be possible to do a 3.6.2 build the same way? And for extra credit, maybe make it a "release" as opposed to "development" build? Seems likely this will be the last 3.x release, so it could be worth the trouble.

I may eventually try to build this for myself now that I know it's possible, but I don't know what was involved in putting this all together.

Reply

• Jul 4, 2021 - 12:32

Ciao Marc.
Nine months have passed, so I do not remember the full details.
I had created a Github repository for the compilation of Qt 5.9.9 for ARM crosscompilation, and its upload to Docker: https://github.com/AntonioBL/qt5DockerMuseScore
here you can find the Docker images:
https://hub.docker.com/r/antoniobl/qt5musescore/tags?page=1&ordering=la…
then I had created the Docker image for packaging: https://github.com/AntonioBL/armpackagingMuseScore
here are the Docker images:
https://hub.docker.com/r/antoniobl/armpackaging/tags?page=1&ordering=la…
And I had used those images to compile and package MuseScore, in branch 3.x of my fork:
https://github.com/AntonioBL/MuseScore/commits/3.x

In principle, I think it just needs 3.x branch to be updated to upstream 3.6.2, but I don't know if the Qt version in the Docker images is still the right one.
At the moment I have very little time to work on it: I am in the middle of renovating the house.

By the way, I am very happy that it works! Does the QtWebEngine part work as well in that package? (It was the one that required the largest effort for the compilation)

Reply

• Jul 4, 2021 - 19:38

Yes, as far as I can tell, the webengine stuff works. I see videos, scores, and other content in the right hand panel of the Start Center, and am prompted to login if I do Save Online. I can't get farther than that, though, I think because it's a development build. Or maybe it was a bug in 3.5.0 specifically, I remember having had the issue back then but somehow it was fixed and I don't remember how.

So, if I have an actual ARM system, do I really need that special cross-compilation stuff? Would it seem likely I could simply install Qt normally and then compile normally? I have no idea what Docker is and have never needed it before when compiling MuseScore on various (Intel-based) Linux systems. But then, I've never tried to build an actual AppImage, either. I suppose that would be nice to share the build with others, but I have no clue how to go about that.

Reply

• Jul 7, 2021 - 14:39

Answering my own question - building 3.6.2 directly on ARM was straightforward. Only slight gotcha is I needed to install the QtQuick controls in addition to the dependencies listed in the compilation instructions, which probably has more to do with the fact that this is a Linux container running within ChromeOS than with it being ARM specifically. But even so, that didn't actually prevent the build from working - it just meant the palettes window was empty where running. FWIW, I don't remember having this issue on other Linux/ChromeOS builds, though.

Anyhow, it's working on my system, so now I am mildly interested in seeing if it can be made into an actual AppImage. But that's totally uncharted territory for me, I have no idea what's involved - except I guess that word "docker" will come into play.

Reply

• Jul 7, 2021 - 16:11

Ciao.
Actually Docker is basically just a virtual machine, which was used to emulate an ARM system.
Indeed, I used a cross compilation to have an ARM build of Qt and then used this inside an ARM virtual image (if I remember correctly). At that time I could not find an official ARM distribution from Qt website.
Did you find an installer of Qt 5.9.9 for ARM Linux?
For AppImage, you simply need to have in the PATH the binary of linuxdeploy and its plugin linuxdeploy-plugin-appimage and linuxdeploy-plugin-qt, and AppImageKit.
(you can compile them from scratch, see for example here: https://github.com/AntonioBL/armpackagingMuseScore/blob/master/Recipe#L… )
You then can (probably) simply launch /MuseScore/build/ci/linux_arm/package.sh

Reply

• Jul 7, 2021 - 19:21

I got Qt directly via apt from the debian buster repository, it was 5.11.3 for whatever reason, but it worked. I am not sure how easy it would have been to get 5.9.9. The online installer didn't seem to offer me good options, so that's when I decided to try the version from the repository.

I take it the package.sh you reference is the one you created in the "linux_arm" directory for your branch? It looks very significantly different from the standard "linux" version of that same script. Is there a reason why simply modifying the standard version with a global search/replace of "x86" to "arm" wouldn't work for me in a local build?

Reply

• Jul 9, 2021 - 09:48

That's why I had to compile Qt 5.9.x from scratch, so that the ARM AppImage could use the same version as that used in all the other operating systems.
Yes, I changed the linux script and I tried to tidy it up (well, maybe my idea of "tidying up" is not really clean...); maybe the standard script works straightforward, since it should assume the default architecture of the operating system (ARM in your case).
Sorry, I wanted to paste the path to the standard linux script, but I accidentally copied the path from my modified branch.
In case of problems, you can have a look at that modified script.
Ciao,
ABL

Reply

• Jul 15, 2021 - 19:08

Thanks for looking at this! I haven't had the time to deal with it myself. My ARM system isn't handy, but I'll test this later. I don't think I did anything special for lame - either enabling or disabling it. I just copied and pasted the commands for installing dependencies from the compile instructions and all worked as expected other than needing to also at QtQuick controls. But I haven't tested MP3 export.

Reply

• Jul 16, 2021 - 06:09

The arm64 build seems to work. It's still flagged as "development" rather than "release", and indeed, mp3 export fails (silently).

I wonder - an AppImage is a kind of fancy archive, right? Would it be somehow possible to replace the executable in one of your AppImage packages with the version I built and have it somehow work?

Reply

• Jul 21, 2021 - 13:31

@Marc Sabatella : I don't think simply changing the executable libraries inside the AppImage would work, since the executable would search for the libraries it was linked against and these are most probably different from those inside the AppImage.
I worked a little more on the AppImage and here are the armhf (32bit) and arm64 AppImages of 3.6.2, release build (I hope), and with a (possibly) working LAME mp3 exporter.
Link to Github artifact: https://github.com/AntonioBL/MuseScore/suites/3293468191/artifacts/7691… (it contains both 32bit and 64bit AppImages, as well as a folder which was used during the compilation)

@karlk62 : Thank you for the testing of the ARM AppImage. The above link should contain a "release" version of 3.6.2 with almost everything working (telemetry will not work, I think).

Ciao,
ABL

Reply

• Jul 22, 2021 - 03:45

@ABL Thank you, thank you, thank you - the arm64 build works as advertised! You have done much over the years to solve a number of thorny problems, but this one earns an extra dose of my personal gratitude!

Now, as for distributing this - do you mind if I pass it along to "the team" to see if they'd be willing to host it on the official server? Or, failing that, if I make it available on my own site? There are a lot of Chromebooks out there that can benefit from this.

Reply

• Jul 22, 2021 - 09:40

Thank you Marc for your kind words.
Of course, you can distribute it, if you want. :-)
I think telemetry will not work, and I am not 100% sure about "save online", but everything else should be working.
Maybe, if the team agrees, they can be distributed as "unofficial, unsupported builds", as it was done with the "No-SSE2" version (or, initially, with the Windows portable version).

Unfortunately, I have very very little time to work on MuseScore in this period. But I see that a lot is going on, so maybe I will try to test the new builds (4.0, master branch) after the dust of the interface changes has settled.
Ciao,
ABL

Reply

• Jul 22, 2021 - 11:04

I echo @Marc Sabatella's words, a great service to arm64 users. I hope I can inform Raspberry Pi 4 arm64 musician users about this package too ? I was stuck on 2.3.2 for a few years, but used your 3.5.0 Dev build for a year or two, and now have the greatest arm64 version on RPi4 so far :-)
I cannot wait for MS4, I know we will wait a little longer for the arm version, but good things come to those who wait :-) Many Thanks ABL & Marc.

Attachment Size
20201113_162055.jpg 145.58 KB

Reply

• Jul 22, 2021 - 15:37

I doubt anyone will complain if telemetry doesn't work :-). "Save Online" does work, in both the previous build and this one.

I will see what I can do about distribution and follow up here when I have news.

Reply

• Dec 11, 2021 - 14:36

I stupidly did not save the armhf AppImage from the build artifact, thinking it would not be relevant to any Chromebooks. It turns out I may have been mistaken. I don't suppose anyone has a copy? The artifact on GitHub has expired.

Reply

• Dec 13, 2021 - 15:32

The most critical part seems to be able to get binaries of Qt 5.15 (used at the moment for MuseScore 4) for ARM systems.
For Qt 5.9.x I created a Github action to cross-compile it and create a Docker image (basically a virtual machine) with those Qt ARM binaries for the cross-compilation of MuseScore.
Maybe simply updating that script and letting Github compile Qt 5.15 could be enough.
Qt 5.9 required a couple of tricks for the cross-compilation, especially the QtWebEngine module.
Is MuseScore 4 still using the QtWebEngine (Chromium) module? I remember reading that the web page visualization part had been rewritten, but I am not sure if we can finally completely ditch that whole module.
(By the way, avoiding the WebEngine module saves a lot of Qt compilation time, roughly 3-4 hours)

I have had no experience yet with Qt 6.x, but I don't think it is already clear if and when MuseScore will start using it.

Reply

• Dec 14, 2021 - 16:30

> No, MuseScore 4 no longer needs or uses QtWebEngine
That's great news.

I managed to compile Qt5.15.2 for armhf and arm64, here, without QtWebEngine.
(It took less than 2 hours for the compilation, instead of almost 6!)
The next steps are: compile MuseScore 4 with these Qt binaries, and package it.

Reply

• Dec 14, 2021 - 16:39

That's even better news! Of course it still pretty earl in the process, who knows what other changes might be coming that could complicate this, but this is definitely encouraging.

Reply

• Dec 27, 2021 - 20:51
Workaround No ⇒ Yes

I just got a new ARM-Based Chromebook for Christmas, and this is the first page that I found when I was having problems with getting any release of Musescore to open on this chromebook. I went to this link and followed their process, and it appears to have worked and got me the latest release on my Chromebook. I just downloaded the 64-bit ARM one and it worked. I kinda got lost in the jargon, so I don't know if this is a fix for y'all's problem or not, but it worked for me.

Reply

• Jan 4, 2022 - 15:44

@Marc Sabatella :
Ciao,
I think I managed to (cross-)compile master branch (4.0) for ARM, 32bit and 64bit.
I had to:
- crosscompile Qt 5.15.2
- use Debian Buster, because gcc at version at least 7 was needed (because of some C++17 functions of std::map)
- disable Unity build
- avoid crashpad_handler installtion, since no ARM binary is present in the repository, but keep crashpad compilation in the diagnostics module, otherwise there was a link order error
- switch to version 13 of AppImageKit (otherwise there was an error in building squashfs library)
- explicitly mark some char enum that contained a "-1" item as signed char

Here is the artifact with both 64 and 32 bit builds (they are still debug builds, I think):
https://github.com/AntonioBL/MuseScore/suites/4828391958/artifacts/1364…
I couldn't test if they really work in real Linux ARM systems.
Ciao,
ABL

Reply

• Jun 1, 2022 - 05:39
Reported version 3.4 ⇒ 3.6

Did this thread ever lead to the creation of a 3.6.2 AppImage for aarch64 that can be shared? I am trying to get MuseScore 3.6.2 working on my Lenovo Duet Chromebook for use as an ultra portable composing/editing platform, and the musescore3 deb package is still stuck on 3.2.3.

Reply

• Dec 17, 2022 - 18:24

Wow, thanks for putting this together! I might not have an opportunity to test on an ARM machine until next week, but will definitely do so as soon as I can.

Reply