This is just a guess, but perhaps this is just someone who's written a script to easily set up a crossdev toolchain.

... which is indeed a very solved problem. Most distributions have RISC-V toolchains packaged and readily available.

you don't even need a dedicated cross compiler if you have clang installed (eg the standard clang you can install from homebrew, or the one shipped with freebsd). you just have to pass it a few flags to target risc v. `clang --target=riscv32 -march=rv32i -mabi=ilp32`

Yes, and I have done this.

I love llvm/clang.

It is odd. It's trivially installable on Debian from any host architecture, even.

Was the previous toolchain all under GPL? This might be the significant change.

This is still GCC, so it's guaranteed to be under the GPL

It could have had clang as a critical step.

Unless the existing one was proprietary, wouldn't this be no change at all since an MIT toolchain gives you everything GPL gives + more.

I think what is nice about this project is that it combines everything in a mono repo which is nice for setting up continuous integration and other testing workflows. This project can be used to build toolchains for newlib (bare metal), musl and glibc. It also will allow building qemu and spike (instruction simulation) simulators to allow running RISC-V code without special hardware. It can then run each project's test suites as well as it has some integration tests (dhrystone).

This repo will be useful for getting started with toolchain development. If you are just a user wanting to write c/c++ app code then use your distro's toolchain packages.

Having a completely Free and Open Source toolchain for a CPU architecture is a great thing to have, which means one can develop tools and other layers on top of it which can be Free and Open Source as well.

Many processors and platforms die because of lack of GNU licensed tools if they fail to be adopted by a critical mass or the developer of the platform doesn't feel like supporting it anymore (Radxa Rock comes into my mind).

So, having an unencumbered and free toolchain ensures that the platform can live on no-matter-what. It's very valuable in my eyes because of that.

I think the person you’re replying to likely knows all this? But thanks, I guess — people doing architecture or compiler research likely don’t need an explanation of the benefits of an open source compiler. In case you are not aware - RISC-V support was added to gcc years ago (I believe it was the first major C compiler targeting it), so the question is what is the significance of this particular repo (which is not an official tool chain source - and hardly unique as far as packaged scripts go) being posted now. I sort of have the same question.

While I know what RISC-V is, and how it's unique among its peers, I'm not very knowledgeable about which toolchain provides which level of support for it.

So, IOW, I wasn't aware the level of support present in RISC-V in GCC, TIL.

Asnwering your question, the README.md vaguely tells me that it provides a single-step, complete cross compilation toolchain to reduce project startup overheads. I consider this repo as an "exploded container" designed to be deployed in a VM to put your code in and get your binaries out. I guess the whole chain is composed of GNUs own tools, or with GPL licensed stuff, so it's not encumbered by anything, or broken by a tool because "we now provide this support in our closed source fork" situations.

The support in gcc and clang for RISC-V is so mature at this point that there are binaries and ports in distributions like Debian, arch, and windows (Msys), *BSD. It would probably be more convenient and reproducible to start with those.

> I consider this repo as an "exploded container" designed to be deployed in a VM to put your code in and get your binaries out.

Only after compiling the whole thing. And it’s not like this does anything special to enforce reproducibility.

On that note there are preexisting docker containers.

Considering this repository started its life in 2014, maybe here's the place where all started, and helped incubating said containers and distro support over the years?

Considering it has 858 forks incl. by corporations like WD Semi and SiFive, I think I'm not too far off in my guess.

No. gcc and clang development do not occur on github and likely never will. Gcc didn’t even use git until relatively recently (not in 2014). You can go look up the mailing list archives - this repo predates nothing.

> helped incubating said containers and distro support over the years?

Tool chain build scripts for gcc and clang have existed for as nearly as long as the respective projects have been around - which in the case of gcc is over 30 years.

Also see https://crosstool-ng.github.io/

Distros like Debian have been packaging cross compilers for decades with their own tooling, long before 2014. MSYS has existed for I can’t remember (long before 2014).

As someone below said - this is a “very solved problem”.

I'm guessing this was posted because RISC-V SBCs are starting to ship, with VisionFive2 and Pine64 recently announcing availability of their boards (although I haven't seen the one from Pine64 in stock yet). Especially with the RaspberryPi shortage, I expect that as RISC-V gains software stability, these boards will start to fill the SBC niche.

Meanwhile, institutions like NASA [0] and the EU [1] are making big investments in the architecture. You can sense the hype by looking at the top submissions in r/riscv [2] from the past year.

I think this architecture is very promising. I'm excited for the ecosystem to mature.

[0] https://www.techspot.com/news/95911-sifive-risc-v-cores-micr...

[1] https://www.hpcwire.com/2022/12/16/europe-to-dish-out-e270-m...

[2] https://old.reddit.com/r/RISCV/top/?sort=top&t=year

Everything needs an upstream. This was the upstream until things got merged, and now most things are linked to.

Still useful to test everything together.