I’m hoping to contribute in a useful way to the Ada open source community once I retire at the end of this year. To that end, I’ve been experimenting with Alire.
I notice that on my M-series MacBook, the “native” version of GNAT that Alire offers is actually x86_64, and generates x86_64 executables. This works because of Rosetta (Apple’s binary translation system), but it’s not ideal. The use of x86_64 on my ARM MacBook is a suitable transitory practice, but I would have expected that by now Alire’s concept of “native” would be an ARM compiler for my host.
I ran into the same problem on my new Windows-on-ARM laptop, but it’s more to be expected there since Windows-on-ARM is less common.
Is there any timeline on when a real native (meaning ARM generating) compiler will be available for macOS or Windows?
As an aside, I notice that the Rust community has a true ARM-native compiler for macOS and Windows. Just sayin’
The reason it is not available by default in Alire is that Alire builds everything using Github’s runners. As there is currently no availability for ARM in Github (though they already announced they plan on letting runners do tasks on ARM OSX), there is no built-in Alire support for Apple-ARM. But you can already use it using the link above and with time it shall become available for everybody else.
Thanks for wanting to help the wider Ada community ^^ Welcome to the forums and good luck with your retirement!
For MacOS, we do have the native build. If you install alire via https://getada.dev on an apple silicone Macbook it’ll automatically install the aarch64 version. Likewise the “Download Alire” button on https://ada-lang.io/ defaults to aarch64 MacOS.
The biggest hurdle to having other platforms besides x64 and aarch64 on mac is that everything (including Alire’s binary releases) is built via Github actions, and github only has aarch64 for macos runners right now. However, that should be changing this year, and I suspect we’ll have at least arm64 builds for linux in 2025.
First, I’m not as concerned about Alire itself. While it would be nice for Alire to be ARM64, I’m more concerned about the architecture of the code produced by the compiler Alire is giving me. Are you saying that the ARM64 version of Alire will also fetch an ARM64 generating version of the compiler?
Second, and this is more an observation than a question, but it seems weird to me that what appears to be the official site for Alire (https://alire.ada.dev/) is only offering an x86_64 version of the program to macOS users when an ARM64 version exists elsewhere. As someone new to Alire, it feels like there might be a lack of coordination within the community.
Alire is mostly platform independent. It uses the compiler you tell it to. So if you tell it to use an ARM64 compiler and one is available it will use it. It can use compilers from its own pool or ones you supply, all at your choice. Hopefully that helps clarify it a bit more?
I would definitely encourage you to reread the reply from @Irvise as it explains this. This isn’t a case of coordination issues. This is a case of what technology supports and doesn’t. Github doesn’t support that architecture for its runners (right now. It will in the future hopefully). Alire relies on Github’s runners, so it cannot handle that architecture built in yet. So as not to leave people that need that architecture out, Alire allows you the user to add compilers that it cannot provide itself (due to lack of support on Github). Hopefully that clarifies it more, but please reread his post.
Great! I can confirm that works. I downloaded the ARM64 version of Alire from ada-lang.io, selected the “native” toolchain, and got a compiler that outputs ARM64 executables. That’s wonderful, thanks!
To be clear, this was on my MacBook. I understand that ARM64 support for Windows isn’t really a thing yet.
I understand that there are some technical issues with GitHub. However, an ARM64 version of Alire and GNAT do exist via ada-lang.io. Why can’t alire.ada.dev link to those resources so everything appears in one place, or is at least consistent between sites?
Someone new to Ada is likely to go to alire.ada.dev to get Alire. There they only see x86_64 tools. Are they going to persevere enough to find a different site where ARM64 tools exist? I’m going to guess many won’t.
In any case, this situation makes the Ada community look fractured. Is there some reason why the people who run alire.ada.dev won’t link to the ARM64 version of Alire on ada-lang.io? Do the people who run those respective sites talk to each other? Is this symptomatic of some kind of internal struggle in the Ada community? Or perhaps the version of Alire on ada-lang.io is substandard in some way. These are the kind of questions I would ask as a newcomer to the community.
Although it is not exactly what is asked for, but it fits to the title.
Maxim Reznik also created an aarch64 (Arm64) version for Linux that works on a recent Raspberry Pi or a Pinebook.
(To install, follow the Readme)
Circleci supports aarch64 runner in the free plan, btw.
ada-lang.io doesn’t have any of the actual Alire binaries, it just points to artifacts produced by the Alire team on GitHub.
AFAIK, there’s been no coordination between the two. There’s a monthly community Ada meeting run by @Irvise, but I don’t know who attends.
I originally started ada-lang.io as an open source community site, but handed it off to Jeremy who runs it due to several important family matters at the time. It’s public and anyone can send a pull request to update it.
Not that I’m aware of. I took some flak for “speaking for the community” from some people with the site, so it probably could be branded better.
Other than learn.adacore.com, the onboarding ramp for people into Ada, especially for cross-platform non-embedded development is much worse than other languages.
The problem for the websites (https://ada-lang.io and https://alire.ada.dev) is that Apple go to considerable lengths to make it impossiblehard for the server to detect the client architecture. The User-Agent string tells you it’s a Mac and whether it’s Safari of Firefox (or, I guess, Chrome, or …) but the rest doesn’t distinguish.
ada-lang.io decided to offer an aarch64 binary for alr; alire.ada.dev still offers the x86_64 binary.
Github has provided aarch64 runners for some time now; there are some limitations, e.g. macos-14 is aarch64, earlier versions are x86_64. There are also Apple’s SDK vagaries. But for the moment things are stable.
If you look at the ALR Release pages (2.0.2 and Nightly) you’ll see that all the parallel releases are at the same date, strongly implying that they were built at the same time in the same environment (Github).
There are at least 3 ways ahead from here:
allow the server to find the client architecture, so the right binary can be downloaded,
provide a universal binary (this requires merging already-built aarch64 and x86_64 binaries, so a change to the build process),
fix alr so it decides which compiler version to download based on the runtime architecture rather than the architecture on which it was built.
A significant issue is that there should really be one domain for important tooling a user is expected to run. Go actually had a different site before consolidating on go.dev. For ages users kept going to the original. One domain means a user can look and say okay I shall trust any downloads from this domain. Currently I think crates are approved manually but github name space attacks that Go made efforts to deal with should also be kept in mind if Ada attracts the growth that it deserves.
That begs the question as to why doesn’t alire.ada.dev link to the ARM64 version for macOS. It seems like alire.ada.dev isn’t being updated to reflect current reality, and that ada-lang.io is a more appropriate place for newcomers to get Alire… something that would not be obvious, particularly given that Alire’s documentation is on alire.ada.dev.
An easier thing would be to provide multiple links: one for the x86_64 version and one for the ARM64 version. Let the user decide which one to download. Given that Alire is targeting developers, it seems reasonable to assume they would know the architecture they want. Also, this approach is common on other websites I’ve seen.
As an aside, I tried installing the x64 version of Alire on my new Windows-on-ARM laptop. It didn’t work at all. Specifically, there is some issue with the handling of the console that causes Alire to print out a large number of blank lines instead of normal text.
I get that it might be a while before there is a native WoA version of Alire, but I just wanted to throw my observations out there for general information.
The trouble with this is that it would require alr to be x86_64, so so that it would work equally on either architecture, which would mean running under Rosetta2 on aarch64, which might confuse users.
(Also, I just spent too long trying to work out how to do this: not helped by the fact that my Ada Language Server setup doesn’t work at all well with the Alire code structure).
It’s great that there are no aarch64 Alire & FSF builds for macOS. I am now trying to figure out what will it take to get aarch64 builds for Linux included?
It would be incredibly useful for building and running Linux applications in Docker containers on macOS without paying the penalty of running an amd64 container.
Maxim Reznik already made one manually:
Using some of these patches:
It is often said the availability of this build depends on ARM runner availability.
GitHub now has ARM runners available:
There are also third-party vendors that provide ARM runners, like WarpBuild:
Who can I reach out to get this done? Would this require somebody sponsoring a runner?
After considerable trouble (note to self: start your development from the latest upstream branch!) I’ve built a macOS universal binary of alr, using the latest (nightly) release; see here.
The release notes say
The new file alr-nightly-bin-universal-macos.zip is intended to run equally well on Intel (x86_64) as Apple (aarch64, aka arm64) silicon.
If you download it using Safari or Firefox (or, probably, any browser) you’ll need to run this in the Terminal
