Updated build for ARM?

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.

Maybe I'm missing something but the Download page does seem to offer AppImages.

But not for ARM anymore, 2.0.3 is the latest AppImage for ARM

Ah!

as noted in the initial post ;-)

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

there is no AppImage though

I just wish we could have the compilation from ManjaroARM64, but I do not know how.

https://archlinuxarm.org/packages/aarch64/musescore

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. )

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.

Wow, you and Eric did a lot of work in early 2018, but now
if ManjaroARM64 can do it then someone has got the ARM64 version working . . . . . . . . ..

... You can do it too

I am so sorry to say it is way beyond my skills. I am a musician & IT hardware repair man, I love Linux, but do not have programming or software engineer skills. :-(

See https://github.com/AntonioBL/MuseScore/actions/runs/286007414 for artifacts you could use for testing whether @ABL's arm64 and armhf work

Duplicate of #105901: ARM AppImage needs to work with non-pulse systems (ALSA-only or Jack)? Or just (remotely) related to?

Thank you Jojo-Schmitz :-)
For people not having a Github account I re-uploaded them here: https://drive.google.com/drive/folders/1Pj2Z_iqnUcWK_1xQ-f-tk8HDy93VTa1…
I would be very glad if anyone could please test them and see if they work, since I cannot directly test them by myself.
They need at least Debian v9 ("Stretch"), or equivalent, for running (it was more difficult to build them for the previous Debian release "Jessie").

Sorry, I unintentionally changed the tag.

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.

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)

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.

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.

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

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?

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

@Marc Sabatella :
I tried to update the branch (actually, a new one for fear of losing the working setup) to 3.6.2.
At the moment I still can't get lame linking to work. And I have a problem with the name of the 32bit armhf artifact.
If you can and want to test, here is the arm64 artifact: https://github.com/AntonioBL/MuseScore/suites/3246637667/artifacts/7540…
(lame and thus mp3 is disabled in this version)
Ciao,
ABL

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.

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?

Thank you @ABL , the link you posted does not work for me, a 404 error. I'd love to test on my Raspberry Pi 4 64 bit OS.
https://github.com/AntonioBL/MuseScore/suites/3246637667/artifacts/7540…

You need a GitHub account for that link to work

I'd forgotten I had one, . . .password reset !
I now have 3.6.2 Dev Build, testing testing :-)
Many Thanks @ABL & Marc S :-)

@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

@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.

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

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.

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.