I’m trying to figure out a pipeline to build gnat-llvm reliably and I was wondering if there is interest for these binaries made public, and maybe added to alire (I would be willing to work to make the builds reproducible to help establish trust), I mainly want to make it easier to experiment with ada in wasm.
Regards.
There’s draft PR to build it for Linux: GNATLLVM for WASM32 target by godunko · Pull Request #83 · alire-project/GNAT-FSF-builds · GitHub
I already asked for it, somewhere.
ah, I see someone already did the work on this, I will have a look see if I can contribute anything to that thread then for now.
edit:
But also looking at the timeline for that the pr is all the way from February and there has been no update really to it, is it still active? And I like the suggestion that was given to build it not only for wasm but for other targets too.
Please, do contribute if you can!
The groundwork has been basically done already as you can see. We now need to test it with the newer GNAT-LLVM v19. And LLVM, unlike GCC, can be compiled in order to support a ton of different architectures! So the “WASM” target can be turned into a “whatever is supported by LLVM” without further changes. The WASM part is that GNAT-LLVM needs to be built in a more specific way so that the WASM RTS (Runtime System) is built as part of the GNAT-LLVM process. You can find more information here: GitHub - godunko/adawebpack: Ada WASM Runtime and Bindings for Web API
Best regards and do not hesitate to ask questions!
Fer
I plan to look into this more on friday/the weekend I might have questions then.
Regards
Quick update, due to personal issues I didn’t have the time to look at anything in the weekend, if anyone is following this, I will look into it this this week hopefully 
I guess, there could be additional interest of this in context of Windows ARM support, where gcc is not available (yet?). It looks like GitHub has corresponding runners. Worth to try?
I’m working on getting the llvm build working with llvm 19 on linux rn, I don’t personally use windows much if at all day to day, but I guess it’s worth to investigate that path if anything to help promote ada as a viable lang for that use case
Ok, I finally had the time to finish up, one thing I’m now wondering is how to call the version should it be like gnat15.2.1-llvm19.1.7 or 15.2.1-llvm9.1.7?
Thank you so much for the work!!! I would say just simply gnat-llvm with the different versions of llvm and gnat combined, such as gnat-llvm v19.1.7-15.2.1. The reason being that GNAT-LLVM is the official name and the versions depend directly on LLVM and the GNAT used. And I feel LLVM’s verion should be first as that is generally more important with regards to the LLVM feature set. But really, this is just my opinion.
Again, thank you so much for your work! Btw, are you building all the target architectures or just the host one? I would personally build all targets (I know this makes the build time a heck of a lot longer) but that also brings WASM and some other interesting targets to the game and allows for super easy cross-compilation!
Best regards,
Fer
Who’s using llvm-9?
Just use the gcc version and then the llvm major number, gnat15.2.1-llvm19, as the major number is apparently the stable version within a series. Although on Gentoo I have llvm:20 and 21 installed now.
I’m inclined to agree with fer on this one actually that the llvm version would be more relevant in this instance.
And the llvm 9 was a typo XD
Ok, so as far as i understand llvm has the nicety of cross compilation without needing a separate build, so my plan is to build amd64 and aarch64 as these are the viable hosts as I see it (if anyone needs riscv host lemme know tho) i made a patch to the gnat-llvm makefile that makes it very easy to use an llvm prefix so you can use any llvm not only system default or the in-tree one. as I found that building with system provided llvm especially when one of the supported versions is not the packaged default was iffy at best. this however brings up the topic of CI each arch that we build llvm for as the host is around 1.4GiB compressed, so we can cache around 2.8GiB of data if we build aarch64 and amd64 hosts, or we rebuild llvm with each build depends on if we care about storage or compute.
Along these lines, I would like to keep the paches very minimal I’m hoping my makefile patch gets upstreamed into gnat-llvm so I can pretty much just keep godunko’s patch as is (adding anod flags)
~/.local/opt/llvm-19.1.7/bin/llc --version
LLVM (http://llvm.org/):
LLVM version 19.1.7
Optimized build.
Default target: x86_64-unknown-linux-gnu
Host CPU: znver3
Registered Targets:
aarch64 - AArch64 (little endian)
aarch64_32 - AArch64 (little endian ILP32)
aarch64_be - AArch64 (big endian)
amdgcn - AMD GCN GPUs
arm - ARM
arm64 - ARM64 (little endian)
arm64_32 - ARM64 (little endian ILP32)
armeb - ARM (big endian)
avr - Atmel AVR Microcontroller
bpf - BPF (host endian)
bpfeb - BPF (big endian)
bpfel - BPF (little endian)
hexagon - Hexagon
lanai - Lanai
loongarch32 - 32-bit LoongArch
loongarch64 - 64-bit LoongArch
mips - MIPS (32-bit big endian)
mips64 - MIPS (64-bit big endian)
mips64el - MIPS (64-bit little endian)
mipsel - MIPS (32-bit little endian)
msp430 - MSP430 [experimental]
nvptx - NVIDIA PTX 32-bit
nvptx64 - NVIDIA PTX 64-bit
ppc32 - PowerPC 32
ppc32le - PowerPC 32 LE
ppc64 - PowerPC 64
ppc64le - PowerPC 64 LE
r600 - AMD GPUs HD2XXX-HD6XXX
riscv32 - 32-bit RISC-V
riscv64 - 64-bit RISC-V
sparc - Sparc
sparcel - Sparc LE
sparcv9 - Sparc V9
systemz - SystemZ
thumb - Thumb
thumbeb - Thumb (big endian)
ve - VE
wasm32 - WebAssembly 32-bit
wasm64 - WebAssembly 64-bit
x86 - 32-bit X86: Pentium-Pro and above
x86-64 - 64-bit X86: EM64T and AMD64
xcore - XCore
This is the supported targets of the llvm I’m building to use with this, I can remove the more exotic ones, but as far as I understand this should cover the multiple targets you mentioned. I can ofc have missunderstood how the platform support on gnat-llvm works and if that’s the case please let me know.
Hi! Yes, all of these targets are what is supported by LLVM and I would like to have them all enabled
The hosts tend to be what Github CI supports by default. So x86 and arm, but we also need to take into account the different OSes, which are currently Windows, Mac and Linux. This should be handled by the Github CI and the Python system used to build all the tools for Alire. Also, I would like if RISC-V as host would be supported
Nice! But keep in mind that LLVM has no stable API/ABI, that mean that it can be incompatible between major versions, so this could lead to a lot of confusion and errors
Feel free to post the patch/github issue and I will try to give some feedback if I have time
Best regards,
Fer
Hey, this is the patch in question
Add option to build with a LLVM prefix or LLVM with suffix instead of system LLVM/in-tree LLVM by xadaemon · Pull Request #61 · AdaCore/gnat-llvm · GitHub the main thing is some distro provided LLVMs are either incomplete or can lackenabled targets, that’s why having a custom built llvm might be worth it in this situation, also this enables pinning of llvm as we can use the custom build which we would always know the exact version of.
edit: also on the topic fer, the built gnat-llvm is independent from the llvm used to build it as far as I can tell, so I don’t see much potential for issues stemming from that. In fact the custom llvm would eliminate such issues, with llvm versioning afaik.
Best regards
I can think of two uses for an external custom llvm install, z80 (unknown if this is up to date) and m68k (enabled with the experimental variable).
I went the external llvm route because some distros (looking at you arch) package llvm in a way that it cannot build a compiler due to missing static libs or other concerns, but this is also a nice reason.