Adding knowledge of libc-variant to alire

[AJ-Ianozi]

This is a continuation of my thoughts on #792 (comment)

Alire has knowledge of gettingos (linux, windows, macos, freebsd, etc), distribution (though I don't see alpine yet as an option), even host-arch (e.g. x86-64) but while Alire is able to be built with musl (such as on alpine) there's no easy way of detecting that from what I can see.

While most distros use glibc, it looks like quite a few are using musl now. I think it's worth adding a libc-variant (or even just libc) parameter (that defaults to being glibc?) or similar that's passed to alire or detected on build. Maybe then gprbuild's toml will look something like:

[origin."case(os)".linux."case(libc-variant)".glibc."case(host-arch)".x86-64]
url = "https://github.com/alire-project/GNAT-FSF-builds/releases/download/gprbuild-22.0.0-1/gprbuild-x86_64-linux-22.0.0-1.tar.gz"
hashes = ["sha256:24dfc1b54655edd4f85589e7e7dbd0bee24d087f25d5b0f13d3224fe7acf85b8"]

[origin."case(os)".linux."case(libc-variant)".musl."case(host-arch)".x86-64]
url = "https://github.com/alire-project/GNAT-FSF-builds/releases/download/gprbuild-22.0.0-1/gprbuild-x86_64-linux-alpine-22.0.0-1.tar.gz"
hashes = ["sha256:hashgoeshere"]

# Would this help for backwards-compatibility?  We default to glibc.

[origin."case(os)".linux."case(host-arch)".x86-64]
url = "https://github.com/alire-project/GNAT-FSF-builds/releases/download/gprbuild-22.0.0-1/gprbuild-x86_64-linux-22.0.0-1.tar.gz"
hashes = ["sha256:24dfc1b54655edd4f85589e7e7dbd0bee24d087f25d5b0f13d3224fe7acf85b8"]

What do you think? As a bonus, a libc-variant could someday be msvc or something on windows.

[mosteo]

It sounds sensible, although my experience outside of the standard situation is limited. I'd like to hear more from people that have to deal with these solutions.

One thought is: do we risk an exponential growth of combinations? I mean, are there other variables besides libc that we are now also implicitly assuming?

[AJ-Ianozi]

My thoughts is that we probably wouldn't more than this.

My goal with this was to emulate something similar to target triples, which is what I've seen being done in both zig and rust.

It looks like this is a standard that started in GCC but LLVM is using it too.

In this case,, x86_64-windows-gnu is 64-bit MinGW, while x86_64-windows-msvc is 64-bit MSVC; some other examples are x86_64-linux-musl (64-bit linux using musl), aarch64-linux-gnu (arm linux using glibc), etc (I'm pulling from Zig's list linked above).

It is possible for some platforms to use 4 entries in their "triple", Rust does this, but it almost always says either "-pc-" or "-unkown-" so it didn't seem relevant for us.

[mosteo]

I see, thanks for the further info. Next question, what would be a reliable way of detecting which libc a system uses? Preferably without introducing new dependencies.

[Fabien-Chouteau]

Do we need special handling for libc when we already have distributions? The use case here is compatibility with Alpine distrib.

origin."case(os)".linux."case(libc-variant)".glibc."case(host-arch)".x86-64

This doesn't look like a solution to me, but rather a slippery slope :)

[AJ-Ianozi]

I see, thanks for the further info. Next question, what would be a reliable way of detecting which libc a system uses? Preferably without introducing new dependencies.

@mosteo I'm slowly looking into this.

Do we need special handling for libc when we already have distributions? The use case here is compatibility with Alpine distrib.

origin."case(os)".linux".case(libc)."glibc".case(host-arch)".x86-64

This doesn't look like a solution to me, but rather a slippery slope :)

@Fabien-Chouteau I played around with the idea of breaking it out by distribution in the other bug report, something like

[origin."case(os)".linux.".case(distribution)."alpine".case(host-arch)".x86-64]

While I'm not against doing this for every distribution that we bring support into that uses musl (there's a growing number), I dropped the idea because you have distros (e.g. Gentoo or Void Linux) that can be either musl or glibc.

Target triples seemed like a sane way of handling this sort of thing in other toolchains; it's nomenclature is used in several examples listed above, and I saw it again used in the void linux link I provided, which is I guess how I was trying to resolve this problem. I know that distribution would get us to where we need to be for alpine today, but not something like gentoo using musl (unless we have a way of detecting gentoo "the standard distribution" vs gentoo "the musl version").