Consider tagging as `riscv64gc` instead of `riscv64`

[zanieb]

ref https://github.com/astral-sh/uv/issues/10883#issuecomment-2611520235

cc @Xeonacid — I'd appreciate your thoughts

[Xeonacid]

From my personal perspective, I am more inclined to use the riscv64 prefix.

In fact, we are currently compiling using the rv64gc extension, which is the default option for riscv64-linux-gnu-gcc. Therefore, the choice of prefix is merely a nominal distinction without any substantive difference.

Most software, such as GCC, uname -m, LLVM, Golang, and notably Python itself, use riscv64 as their prefix. This is due to the following two reasons:

1. All Linux distributions (Ubuntu, Debian, Fedora, Arch Linux, etc.) use rv64gc as their baseline. Hence, software running on riscv64 Linux can assume that the GC extension is available.
2. GC is just an instruction set extension. Just as we might compile with -march=avx2 on x86, we don't refer to it as x86_64-avx2-linux, do we?

Rust is a unique case, as it uses the riscv64gc prefix for its target. Honestly, I can't think of another example.

This design choice in Rust has been a source of considerable frustration. Many software developed with Rust have to determine whether to call the riscv64 prefix GCC if the current target is riscv64gc prefix, or vice versa.

I am not an expert on uv, so I don't know why uv uses the riscv64gc prefix. However, I suspect that uv uses the same target as Rust. In that case, I believe a better approach would be to follow the practice of other software and make a special case to use the riscv64 prefix.

[zanieb]

Thanks for the details!

GC is just an instruction set extension. Just as we might compile with -march=avx2 on x86, we don't refer to it as x86_64-avx2-linux, do we?

We actually use different variants for this, yeah — that's why we have x86_64_v2 etc. (covered in https://gregoryszorc.com/docs/python-build-standalone/main/running.html#obtaining-distributions)

I am not an expert on uv, so I don't know why uv uses the riscv64gc prefix.

We infer this from the system using the target_lexicon crate, yeah.

Overall, if it's not realistic that we'd ever ship builds that work on riscv64 without the gc prefix I'm fine leaving it as-is unless we hear additional feedback.