Some people have already expressed their willingness to sponsor some runners… I suppose @mosteo and @Fabien.C have the final word on this
Best,
Fer
Some people have already expressed their willingness to sponsor some runners… I suppose @mosteo and @Fabien.C have the final word on this
Best,
Fer
I’m definitely willing to give it a try, but I wonder about the costs as we run quite some workflows per PR. Maybe, if GH own runners are around the corner, it’s simply a matter of waiting a bit.
According to the roadmap, it’s planned for 2025Q1, although it was already delayed from 2024Q4, so who knows.
@mosteo GH has ARM runners as part of Large Runners (available for organizations and enterprises using the GitHub Team or GitHub Enterprise Cloud plans), but 1:1-compatible runners on WarpBuild start at $0.003 per minute, which is $0.18/hour. That’s for 2 vCPU, 7GB – and if that’s insufficient, there is room for growth.
Considering that we don’t necessarily need to run these jobs on every change but only on releases, this should not be a massive cost. In either case, I’d happily support this effort if necessary.
I just saw that the ARM runners of GH are now available for public repos! GitHub Linux ARM64 hosted runners now available for free in public repositories | Hacker News @Max @Fabien.C and @mosteo (linux only though)
Also, fyi @simonjwright, there is now a HN thread about porting GNAT to ARM64 OSX, Porting the GNAT Ada compiler to macOS/aarch64 | Hacker News
msys2 on Windows is not strictly required; theoretically one would lose access to system crates and one may be required to provide some tools by other means, but alr itself should still work. If not, we’ll want to fix it as we did in the past.
I just tried to manually ssh in a GitHub ARM runner and I could build and alr init
and alr run
on the first try…
I’ve filled a PR to bootstrap AArch64/Linux gnat 14.2 compiler using GCC from Ubuntu. I hope this helps to build gnat_native on this platform.
It was cool to see Alire show up in the package repo on my new Raspberry Pi 5.
paul@tegu:~/dev/ada/ $ sudo apt search alire
Sorting... Done
Full Text Search... Done
alire/stable,now 1.2.1-1 arm64 [installed]
Ada package manager.
Toolchain select doesn’t seem to work. Maybe I need to change indexes?
paul@tegu:~/dev/ada/hello_raspberry $ alr toolchain --select
Welcome to the toolchain selection assistant
In this assistant you can set up the default toolchain to be used with any crate
that does not specify its own top-level dependency on a version of gnat or
gprbuild.
If you choose "None", Alire will use whatever version is found in the
environment.
ⓘ gnat is currently not configured. (alr will use the version found in the environment.)
⚠ No indexed versions in the catalog for crate gnat
ⓘ gprbuild is currently not configured. (alr will use the version found in the environment.)
⚠ No indexed versions in the catalog for crate gprbuild
Installing gnat
and gprbuild
from apt
made build work just fine:
sudo apt install gnat gprbuild
Result:
paul@tegu:~/dev/ada/hello_raspberry $ alr build
ⓘ Building hello_raspberry/hello_raspberry.gpr...
Setup
[mkdir] object directory for project Hello_Raspberry
[mkdir] exec directory for project Hello_Raspberry
Compile
[Ada] hello_raspberry.adb
Bind
[gprbind] hello_raspberry.bexch
[Ada] hello_raspberry.ali
Link
[link] hello_raspberry.adb
Build finished successfully in 0.78 seconds.
I haven’t tried building anything complicated yet, but this looks good.
paul@tegu:~/dev/ada/hello_raspberry $ file bin/hello_raspberry
bin/hello_raspberry: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=e94b206f6086a530d467c2e07e28d85df35b1624, for GNU/Linux 3.7.0, with debug_info, not stripped
I am building very complicated things on native aarm64 and armhf for years. Everything works just fine. However one should be very careful with the -j switch. -j0 will usually end up swapping which then promptly crashes Linux. -j is important because Raspberry is very slow.
P.S. If you plan to use graphics, I would recommend to replace Wayland with X11. Wayland has bugs, at least when GtkAda is used.
Sadly, the APT/Debian repo package for Alire is quite old… Still in v1.2, so newer indexed packages will not work…
Would you be up for trying to install the latest version of alire via getada on the pi? I don’t actually have a pi, so I haven’t been able to fully test it yet. curl --proto '=https' -sSf https://www.getada.dev/init.sh | sh
should “just work” though!
I’ll try this tonight, if I can find the pi zero hiding somewhere in my office, I’ll try it on that too. I was going to do a little blog post and was curious what we could do to update on the Alire version in the rep. It looks like @stcarrez owns it, but if he needs help I’m willing to learn how to help update and test it.
@AJ-Ianozi - getada doesn’t work on my Raspberry Pi 5
paul@tegu:~/dev/ada/hello_raspberry $ curl --proto '=https' -sSf https://www.getada.dev/init.sh | sh
info: downloading installer
Welcome to the unofficial Alire Installer ("GetAda") v1.0.2!
Alire is the official Ada Package Manager. For more information
please visit https://ada-lang.io or https://alire.ada.dev
Copyright (C) 2022-2024 A.J. Ianozi licensed GPL3.
No version has been specified. Will attempt to install the latest version of Alire.
(To specify a version, pass --alire-version=x.y.z)
Temporary files will be stored in a folder in:
/tmp
(This can be changed with the "TMPDIR" environment variable or passing --tmp=/directory/here)
Any of alire's scripts or helper files will store in the following location:
/home/paul/.getada
(This can be changed either by setting the "GETADA_CFG" environment variable or passing --cfg=/directory/here)
Alire's binary will be installed as "alr" in the following location:
/home/paul/.getada/bin
(This can be changed either by setting the "GETADA_BIN" environment variable or passing --bin=/directory/here)
This path will be added to your local PATH variable by modifying the following files:
/home/paul/.profile
(This can be changed by passing --no-path)
You can revert everything that was done by re-running GetAda with the --uninstall option.
Continue with installation? [y/n] (press "enter" with no input for interactive mode) >y
Downloading https://github.com/alire-project/alire/releases/download/v2.1.0/alr-2.1.0-bin-aarch64-linux.zip to /tmp/tmp.JWshkxz3me7iSB25/alr-2.1.0-bin-aarch64-linux.zip
Creating Directory: /home/paul/.getada
Creating Directory: /home/paul/.getada/bin
Extracting: /tmp/tmp.JWshkxz3me7iSB25/alr-2.1.0-bin-aarch64-linux.zip to /home/paul/.getada/bin
Copying /tmp/tmp.s5XvWE918X/getada to /home/paul/.getada/bin/getada
Testing binary by running "/home/paul/.getada/bin/alr --version"
Unable to run binary... Attempting to troubleshoot.
Attempting "/bin/chmod +x /home/paul/.getada/bin/alr"
Testing binary by running "/home/paul/.getada/bin/alr --version"
/home/paul/.getada/bin/alr: /lib/aarch64-linux-gnu/libc.so.6: version `GLIBC_2.38' not found (required by /home/paul/.getada/bin/alr)
Unable to run binary... Attempting to troubleshoot.
Something went wrong... Aborting installation...
Attempting to save log in HOME directory:/home/paul/log.dat
Attempting to roll back to state before installer ran
Uninstalling...
Removing: /home/paul/.getada/bin/alr
Removing: /home/paul/.getada/bin/getada
Removing: /home/paul/.getada/bin
Removing: /home/paul/.getada
Alire has (hopefully) been uninstalled.
To reinstall, please visit https://www.getada.dev/
Please press any key to continue.
If filing a bug report, please attach the log.
raised DEFAULTS.INVALID_FILE : /home/paul/.getada/bin/getada is not a valid executible by this system.
[/tmp/tmp.s5XvWE918X/getada]
0x4442f4 installer__install at ???
0x403e2c _ada_getada at ???
0x403a30 main at ???
[/lib/aarch64-linux-gnu/libc.so.6]
0x7fff7acf773c
0x7fff7acf7814
[/tmp/tmp.s5XvWE918X/getada]
0x403b2c _start at ???
0xfffffffffffffffc
Looks like loader error on glibc, alr
wants 2.38 and my Raspberry Pi 5 has 2.36
paul@tegu:~/dev/ada/hello_raspberry $ cp /tmp/tmp.N4gB1ET80TSB5Wlm/alr-2.1.0-bin-aarch64-linux.zip ../
paul@tegu:~/dev/ada/hello_raspberry $ cd ../
paul@tegu:~/dev/ada $ file bin/alr
bin/alr: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=4737f4ffe4f87c79dab9cb235d6e2e47e6e5789f, for GNU/Linux 3.7.0, with debug_info, not stripped
paul@tegu:~/dev/ada $ bin/alr
bin/alr: /lib/aarch64-linux-gnu/libc.so.6: version `GLIBC_2.38' not found (required by bin/alr)
paul@tegu:~/dev/ada $ ldd bin/alr
bin/alr: /lib/aarch64-linux-gnu/libc.so.6: version `GLIBC_2.38' not found (required by bin/alr)
linux-vdso.so.1 (0x00007fff8f72c000)
libgcc_s.so.1 => /lib/aarch64-linux-gnu/libgcc_s.so.1 (0x00007fff8e1e0000)
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x00007fff8e020000)
/lib/ld-linux-aarch64.so.1 (0x00007fff8f6f4000)
glibc version available:
paul@tegu:~/dev/ada $ /lib/aarch64-linux-gnu/libc.so.6
GNU C Library (Debian GLIBC 2.36-9+rpt2+deb12u10) stable release version 2.36.
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 12.2.0.
libc ABIs: UNIQUE ABSOLUTE
Minimum supported kernel: 3.7.0
For bug reporting instructions, please see:
<http://www.debian.org/Bugs/>.
So this is interesting… The getada
binary itself is running fine, but something seems wrong with the binary on alire. Can you try downloading and running the binary directly from Alire’s github release page?
This is the one: https://github.com/alire-project/alire/releases/download/v2.1.0/alr-2.1.0-bin-aarch64-linux.zip
I get the same error with the one directly downloaded.
The
getada
binary itself is running fine, but something seems wrong with the binary on alire.
getada is doing it’s job, it’s an Alire executable error. The error is that the loader can’t find the correct glibc library version that’s been linked in when alr
was built. (The loader locates the appropriate shared library that a program was built against at program execution, and maps it in memory for the program). It looks like the OS version I’m running on the Raspberry Pi 5 has an older glibc version. I haven’t written Ada in a while, so I missed that the Alire version in the package repository was 1.2 and we’re on 2.1 now.
This is what I should have posted before, but didn’t know how to do, for the alr
version pulled by getada
:
paul@tegu:~/dev/ada $ ldd -v bin/alr
bin/alr: /lib/aarch64-linux-gnu/libc.so.6: version `GLIBC_2.38' not found (required by bin/alr)
linux-vdso.so.1 (0x00007fff11ad8000)
libgcc_s.so.1 => /lib/aarch64-linux-gnu/libgcc_s.so.1 (0x00007fff10580000)
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x00007fff103c0000)
/lib/ld-linux-aarch64.so.1 (0x00007fff11aa0000)
Version information:
bin/alr:
ld-linux-aarch64.so.1 (GLIBC_2.17) => /lib/ld-linux-aarch64.so.1
libgcc_s.so.1 (GCC_3.3) => /lib/aarch64-linux-gnu/libgcc_s.so.1
libgcc_s.so.1 (GCC_3.0) => /lib/aarch64-linux-gnu/libgcc_s.so.1
libgcc_s.so.1 (GCC_4.2.0) => /lib/aarch64-linux-gnu/libgcc_s.so.1
libc.so.6 (GLIBC_2.38) => not found
libc.so.6 (GLIBC_2.34) => /lib/aarch64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.32) => /lib/aarch64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.28) => /lib/aarch64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.33) => /lib/aarch64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.17) => /lib/aarch64-linux-gnu/libc.so.6
/lib/aarch64-linux-gnu/libgcc_s.so.1:
libc.so.6 (GLIBC_2.35) => /lib/aarch64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.34) => /lib/aarch64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.17) => /lib/aarch64-linux-gnu/libc.so.6
/lib/aarch64-linux-gnu/libc.so.6:
ld-linux-aarch64.so.1 (GLIBC_2.35) => /lib/ld-linux-aarch64.so.1
ld-linux-aarch64.so.1 (GLIBC_PRIVATE) => /lib/ld-linux-aarch64.so.1
ld-linux-aarch64.so.1 (GLIBC_2.17) => /lib/ld-linux-aarch64.so.1
Examining the alire 1.2 version I can grab with apt, it looks like it’s using the 2.36 version:
paul@tegu:~/dev/ada $ ldd /usr/bin/alr
linux-vdso.so.1 (0x00007fff81890000)
libgnatcoll.so.21 => /lib/aarch64-linux-gnu/libgnatcoll.so.21 (0x00007fff802a0000)
libxmlezout.so.7 => /lib/aarch64-linux-gnu/libxmlezout.so.7 (0x00007fff80260000)
libgnarl-12.so => /lib/aarch64-linux-gnu/libgnarl-12.so (0x00007fff801f0000)
libgnat-12.so => /lib/aarch64-linux-gnu/libgnat-12.so (0x00007fff7fdb0000)
libgcc_s.so.1 => /lib/aarch64-linux-gnu/libgcc_s.so.1 (0x00007fff7fd70000)
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x00007fff7fbb0000)
libgnatprj.so.10 => /lib/aarch64-linux-gnu/libgnatprj.so.10 (0x00007fff7f240000)
libxmlada_schema.so.7 => /lib/aarch64-linux-gnu/libxmlada_schema.so.7 (0x00007fff7f160000)
libxmlada_dom.so.8 => /lib/aarch64-linux-gnu/libxmlada_dom.so.8 (0x00007fff7f120000)
libxmlada_sax.so.7 => /lib/aarch64-linux-gnu/libxmlada_sax.so.7 (0x00007fff7f0b0000)
libxmlada_input.so.7 => /lib/aarch64-linux-gnu/libxmlada_input.so.7 (0x00007fff7f080000)
libxmlada_unicode.so.7 => /lib/aarch64-linux-gnu/libxmlada_unicode.so.7 (0x00007fff7ece0000)
/lib/ld-linux-aarch64.so.1 (0x00007fff81858000)
libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x00007fff7ec40000)
I’ve never played with Raspberry Pi before, this is the OS I’m running.
paul@tegu:~/dev/ada $ uname -a
Linux tegu 6.6.51+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.6.51-1+rpt3 (2024-10-08) aarch64 GNU/Linux
@AJ-Ianozi Here’s a full write-up:
Try to install Alire from nightly build release. I sent pull request with a fix for building it on ubuntu-22.04.