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

Peg to a release? #36

Open
bradjc opened this issue Jun 15, 2020 · 3 comments
Open

Peg to a release? #36

bradjc opened this issue Jun 15, 2020 · 3 comments

Comments

@bradjc
Copy link
Contributor

bradjc commented Jun 15, 2020

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
Copy link
Collaborator

sbeamer commented Jun 25, 2020

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
Copy link
Contributor

tuupola commented Sep 14, 2021

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

Ray-Eldath commented Oct 1, 2021

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

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

4 participants