I am having some trouble with my recent pull requests for the Pi-Ada-Tutorial regarding Windows compatibility. Everything builds and passes the GitHub Actions CI perfectly on Linux and macOS, but Windows is blocking the PRs.
Here is the exact breakdown of what is happening on Windows:
In GitHub Actions (CI): Both light_tasking_rp2040 and embedded_rp2040 fail to build on the Windows runner.
Locally (Windows):light_tasking_rp2040 actually builds fine on my machine, but embedded_rp2040 fails locally as well.
If anyone here has experience debugging Alire/Raspberry Pi Pico cross-compilation environments specifically under Windows, I would really appreciate your insight.
(Note: There are quite a few pull requests open right now. I initially opened a single PR for the Pi Ada Tutorial release 1.7.0 to save the moderators some work, but when the Windows CI failed, I split it into 10 separate pull requests—one for each crate).
The error message that is happening on the Alire Index Windows CI is this:
rp-timer-interrupts.adb:7:06: error: "ADA.INTERRUPTS.NAMES" is not a predefined library unit
It feels like the build of rp2040_hal can’t see the libgnarl sources for some reason, even though I can see libgnarl being built in the logs (a-realtim.adb is getting compiled, for example).
For context, the runtime is split into two libraries: libgnat for the sequential (non-tasking) stuff, and libgnarl for the tasking stuff. They are built by the projects runtime_build.gpr and ravenscar_build.gpr respectively. It feels like the build of rp2040_hal is not able to see the libgnarl part of the runtime for some reason, though I don’t know why that would happen on Windows only.
Could you try adding this to the top of your GPR file (e.g. pico2_ada_c07_buzzer.gpr):
with "ravenscar_build.gpr";
Usually, Alire should auto-with this file in its generated *_config.gpr file, but I’ve seen cases in the past where it does not do this which has caused problems. The instructions on the runtime crate’s page state to “with” both runtime_build.gpr and ravenscar_build.gpr, so adding it explicitly might help with this problem too.
That’s a shame. It was a bit of a stab in the dark anyway.
Since you’re able to reproduce it locally (at least with the embedded_rp2040 runtime), here’s some ideas for other things you could try to help narrow down the cause:
try downgrading the runtime crate version to 15.3.0. As far as I know, this problem has only ever happened with the most recent version (15.4.0)
try forcing a clean build with alr clean and then alr build to see if that makes a difference.
It’s very confusing why this happens on Windows but not Linux, and why there’s a difference between your local Windows and the CI (at least for light_tasking_rp2040). It doesn’t seem entirely repeatable.
The only possible thing I can think of is that it’s something to do with how the runtime handles multiple variants of package Ada.Interrupts.Names (one version for single-core and another for multicore). Normally, the filename is a-intnam.ads, but the ravenscar_build.gpr file uses a for Spec ("Ada.Interrupts.Names") use clause to select between two files: a-intnam-1.ads and a-intnam-2.ads depending on the chosen configuration.
If, for some reason, the compiler doesn’t know about that file renaming clause when building rp2040_hal then it will probably look for a file called a-intnam.ads which doesn’t exist, and so it thinks the package doesn’t exist.
But then the question is why does this only happen on Windows and not Linux? And why has it only started happening now? Very strange…
That’s the “alr dev” CI that uses the 3.0.0 development version. The Alire index actually runs two Windows CIs, one with the latest release version (2.1.0) and one with the development version (3.0.0), presumably for some kind of testing with it.
In any case, both 2.1.0 and 3.0.0 exhibit the same error in their logs.