Peg to a release?

[bradjc]

Right now, using this tap installs the toolchain from the master branch of riscv-gnu-toolchain, and means that the version of the compiler one gets is based on when they run brew tap. Since that can be updated at any time, an unlucky user can get a version that doesn't work (right now we are running into riscvarchive/riscv-gcc#190). This makes it hard to rely on using this tap, since we don't want to tell users to install the toolchain this way and for them to have unexpected errors because they aren't using a stable release.

Any thoughts on tying these formulas to a release? Even just having the versions in the git history would make it easier to go back to a known working version.

[sbeamer]

Not a bad idea.

Considering https://github.com/riscv/riscv-gnu-toolchain doesn't tag releases, the best bet would probably be to use the upstreamed gcc and use their tags. This new formula could borrow a lot of code from the native gcc. If folks want the stability of a versioned release, would they be ok with using glibc instead of newlib?

[tuupola]

Commit date could probably also be used for versioning the Homebrew package. This way brew install would install a version known to work and those who want bleeding edge can still do brew install --HEAD.

[Ray-Eldath]

I've found that gdb-10 can't really understand DWARF spitted by gcc-11, since when print some variables in gdb console it'll errored with Corruptted DWARF. in my Linux machine this could fix by downgrade gcc to gcc-10, thus the version of gcc and gdb now matched. but i dont know how to fix this when using homebrew......