Add arm64 Linux Support with Docker and CI #1000
Conversation
|
Congrats on the 1K 🎊 Could you explain why we want arm64 as additional platform, beyond "because we can"? Further I believe that there is a native GitHub partner image for arm64, so without needing Docker: https://github.com/actions/partner-runner-images |
|
Thanks for the feedback! I just want to clarify that my addition was specifically for ARM64 Linux (aarch64 / v8), not AMD64. Support for this platform is meant to ensure reliable builds and tests on ARM64, which is increasingly common on new hardware. In fact—to be honest, I added it because that's the type of Linux I use. While it's uncommon, I believe it's necessary to make sure CPAL supports all platforms. It's the same reason we have a Github Action and support for armv7, even though amd64 is also supported. This workflow doesn’t interfere with any other platforms. It's a separate runner from armv7. Additionally, using Docker was needed for armv7, and armv8 linux, as this ensures they have libasound, libjack-jackd2, and other dependencies, which are required to properly use CPAL on these platforms. I'm not entirely sure why there isn't a dockerfile for x86_64 linux, as those same dependencies are required on that platform. Happy to adjust the workflow if needed, but I think ARM64 coverage will be valuable for contributors and users alike. |
|
My apologies—I was confused why my PR failed. I thought that was a security measure. Turns out I just didn't spell |
Yes, spelling mistake on my end. I edited my initial response to correct it. The URL to the image should still be valid.
Sure but I am questioning what we would expect from it. Same for armv7, by the way. What kind of regressions or compilation issues on Linux could we expect between one architecture and the other? And it there were any, would that more likely be with the Alsa or jack bindings or with our own code? |
|
Good morning. I understand what you're saying. Implementing too many CI, while it won't necessarily have a significant direct cost, could simply be unnecessary. My line of thinking was that, even if an issue occurred in Now, for issues that could occur in armv8 but not in armv7, etc, there is potential for this to occur. For example, arm64 imposes significantly stronger memory-access restrictions, and, given ALSA is largely about audio buffers, these restrictions are inevitable. While we don't need to worry about these so much with Rust, If the CI workflow doesn't seem necessary enough, we could remove that and just keep the Dockerfile.arm64, allowing test and build support for arm64 if needed without the consistency of the workflow. |
|
I thought about this for a while, and I think I'm seeing what you're saying. Adding another CI workflow, or another Dockerfile might not have an immediate impact, but I see how it could cause confusion or disorganization later. I still think what I made was fine for it's purpose (allowing arm Linux testing across different versions), but if you'd like, I could make this a lot simpler. I could remove the Dockerfile.arm64, and create a combined Dockerfile with if-statements. I would need to address the linux runner for armv7, which uses that Dockerfile, but this wouldn't take me much time. In fact, another thought—arm32 (armv7) is increasingly rare to find, while arm64 (armv8) is becoming more popular, especially as Windows 11 introduces the Surface series and MacOS introduces M-series chips. Replacing armv7 could be another idea for this, though that's entirely up to you. |
|
Yes, I think that we can save the moment for adding more cross-compilation targets for if and when it turns out there are platform-specific things that we need to safeguard against, and e.g. Alsa itself can’t. Your point about arm64 overtaking armv7 is a good one though. Still I’d like to reuse as much of the standard GitHub images though if we can, without maintaining own Docker files. @est31 what history can you share on multi-architecture testing? For example, why are we testing Windows both on i686 and x86_64? What’s your take? |
I think it makes sense for a cross platform crate like cpal to test on platforms with different default integer widths. We interface with C APIs and the integer type used might differ depending on the architecture (plus alignment etc). This means that we should have a slightly larger test matrix than some crate that only builds on cross platform primitives. |
|
Ah yes, that makes sense. 👍 So let's go ahead with adding arm64 Linux, and without Docker if we can. |
|
@roderickvd That sounds great. Now, |
Yes. I believe you should just be able to specify |
I added basic support for arm64 Linux to CPAL by introducing a new
Dockerfile.arm64to provide a ready-to-use environment for arm64 systems.Additionally, the PR includes a new GitHub Actions workflow configured to run a GitHub-hosted ubuntu-22.04-arm64 runner, which automatically builds and tests CPAL on arm64 Linux for every push and pull request. Manual testing has verified that the Docker environment builds and runs tests correctly on arm64 hardware. I also added an entry to
CHANGELOG.mdto include these changes.Hopefully this is a good 1000th PR for CPAL. I didn't want to mess this one up!