Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider tagging as riscv64gc instead of riscv64 #504

Open
zanieb opened this issue Jan 24, 2025 · 2 comments
Open

Consider tagging as riscv64gc instead of riscv64 #504

zanieb opened this issue Jan 24, 2025 · 2 comments

Comments

@zanieb
Copy link
Member

zanieb commented Jan 24, 2025

ref astral-sh/uv#10883 (comment)

cc @Xeonacid — I'd appreciate your thoughts

@Xeonacid
Copy link
Contributor

Xeonacid commented Jan 24, 2025

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
Copy link
Member Author

zanieb commented Jan 24, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants