search

riscv-software-src / homebrew-riscv

homebrew (macOS) packages for RISC-V toolchain
https://riscv.org
310 stars 50 forks source link

Peg to a release? #36

Open bradjc opened 4 years ago

bradjc commented 4 years ago

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 https://github.com/riscv/riscv-gcc/issues/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 commented 4 years ago

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 commented 3 years ago

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 commented 3 years ago

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......