3 ms·

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 explanati

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, especially for RISC-V. 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 (hardly unique as far as packaged scripts go - it seems to just pull in the various upstream components as submodules) being posted now. I sort of have the same question.

bayindirh 4y ago
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.
- riceart 4y ago
  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.
  - bayindirh 4y ago
    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.
    - riceart 4y ago
      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/ 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”. Not that this repo isn’t useful - but I think posted here out of context clearly it is conveying the impression that it is bringing something novel to RISC-V which isn’t the case.

bayindirh 4y ago

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.

riceart 4y ago
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.
- bayindirh 4y ago
  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.
  - riceart 4y ago
    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/ 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”. Not that this repo isn’t useful - but I think posted here out of context clearly it is conveying the impression that it is bringing something novel to RISC-V which isn’t the case.