-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Aarch64 (ARM64) Linux builds fail to launch when using a kernel with 16 KB PAGESIZE (please add support for other kernel page sizes?) #20342
Comments
This is a build configuration problem. Basically every ARM64 Linux distro has defaulted to 64K segment alignment for years, to support all page sizes correctly. It looks like that libsndfile.so.1 is built for 4K segment alignment. I assume that comes from the AppImage - is it some really old build, or was it built with a niche compiler/build environment with bad defaults or something like that? (Needless to say, distribution builds of MuseScore from e.g. Fedora work perfectly fine on 16K page systems, so this is something specific about the official ARM64 builds - OP: you should be able to just |
It seems libsndfile from apt is used; see MuseScore/build/ci/linux/setup-arm.sh Line 85 in efbc260
@theofficialgman What are your thoughts about this issue? |
I can't comment more now as I am short on time (will have more next week). But yes I am aware that the ubuntu provided libsndfile binary fails on 16K pagesizes within the appimage (we saw this on Pi5 on PiOS Bookworm as well at pi-apps Botspot/pi-apps@e4a484c). Not sure whats wrong with it because I did check the elfheader three weeks ago of the
CC @marcan the above disproves your theory I think. Feel free to certify yourself though, the binary comes from ubuntu focal libsndfile1 package http://ports.ubuntu.com/pool/main/libs/libsndfile/libsndfile1_1.0.28-7ubuntu0.2_arm64.deb |
oh huh... interesting
|
Is there some weird ELF mangling going on as part of the AppImage build process? In the original file GNU_RELRO and DYNAMIC sections are part of the data pheader too, while in the new file they are not. It sounds to me like something is patching the DYNAMIC section, and in the process moving it out of the existing LOAD pheader and adding a new one... and getting the section alignment wrong. |
Yup, this is patchelf's fault: NixOS/patchelf#474 |
Actually, not so sure. It looks like patchelf correctly considers the base page size for ARM64 to be 64K: https://github.com/NixOS/patchelf/blame/917ea45b79de04f69059f42a8e2621f7caeae1c9/src/patchelf.cc#L361 Is this build of patchelf built using |
I looks to me like linuxdeploy handles copying, stripping, and setting the RPATH in the binaries as part of the appimage build process |
yup, bug has been found.
|
and the patchelf bug that was fixed in 0.12 that causes this NixOS/patchelf@0470d69 .... focal has 0.10
|
patchelf 0.14.3 from jammy builds fine on ubuntu bionic in my testing (that just what I had easily available). I'll add it to a ppa or the setup script edit: ppa made https://launchpad.net/~theofficialgman/+archive/ubuntu/patchelf waiting on launchpad to publish |
3+-year-old software strikes again... (also hi @delroth). FWIW, this is a theme in ARM64 land. If you are using any frameworks, builds, tools, etc. that are more than 2 years old, they are highly likely to be buggy or broken in some way. ARM64 Linux is only just taking off, and things were very broken just a few years ago. Even if you wouldn't do so otherwise on x86-64 for e.g. better host system compat, you're much better off going for newer stuff on ARM64. It's not just stuff like this; e.g. I got major Qt (QML javascript crashing) and GCC (miscompiling) bugs fixed and very recently a glibc bug fixed (TLS segfaults with dynamic loading). |
Issue type
Crash or freeze
Bug description
Aarch64/ARM64 Linux builds seem to basically crash on startup if kernel PAGESIZE is 16 KB (not 4 KB).
Suggestion: please also support other page sizes than 4 KB?
16 KB support is required for at least these:
More information: on ARM, 4 KB is not the only PAGESIZE possible (some systems use 16 KB or 64 KB).
I tested with Aarch64 (ARM64) Linux on an "Apple Silicon" (ARM64) M1 MacBook Air, (re)booting straight to bare Asahi Linux / Fedora Asahi Remix "on the metal" (without using macOS), and the Asahi Linux kernel will only have support for 16 KB page size, because that's what the hardware expects.
Here is some more information about "broken" software that doesn't yet work on ARM64 Asahi Linux (includes links to details on how several previously unsupported applications have already been fixed to support 16 KB page size!):
https://github.com/AsahiLinux/docs/wiki/Broken-Software#if-package-supports-aarch64-why-doesnt-it-work
(random example link from that page about Chromium (fixed in 2022): "ARM64 supports 4kb, 16kb, and 64kb page sizes. Previously, only 4kb was supported by Chromium. This patch adds 16kb support, as is used for example by Asahi Linux on M1 Macs")
PS. Why I'm reporting this: The 4.2 Beta 2 announcement added experimental builds for ARM Linux and asked to "Please let us know if you encounter any issues."
Also, I was able to quickly test (on macOS, using QEMM in UTM) that the same build did work in a similar Fedora 39 ARM64 VM that was using 4K pages, so I'm pretty sure 16K support is the issue here (i.e. not a Fedora bug).
Steps to reproduce
What happens (doesn't open at all, only shows an error message):
(the same problem also happens with the latest arm64 Linux nightly)
Screenshots/Screen recordings
No response
MuseScore Version
MuseScore 4.2 Beta 2 (Pre-release)
Regression
No.
Operating system
Fedora Asahi Remix 39 (ARM64 Linux)
Additional context
No response
The text was updated successfully, but these errors were encountered: