-
Notifications
You must be signed in to change notification settings - Fork 243
Linker errors with stm32g4-0.13.0 and cortex-m-rt-0.7.0 #602
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
Comments
The underlying problem is that However, Cargo should detect this and fail the build early with a helpful error message, because cortex-m-rt 0.6.14 and 0.7.0 both define a In the short term, you could use the git dependency https://github.com/stm32-rs/stm32-rs-nightlies, which does work with cortex-m-rt 0.7, and in the medium term I expect to release stm32g4 v0.14 in the next ~week, which should also resolve the issue. That said, no idea why it's giving such unhelpful errors. Possibly the version brought in by stm32g4 isn't actually being linked in, and consequently it's not defining those symbols... not sure. |
Thanks, now I understand. It seems that cortex-m-rt <= 0.6.14 didn't set the If I set |
Aah, of course, you've nailed it. Indeed, the links field is only added in the latest cortex-m-rt release, and for whatever reason Cargo chooses 0.6.14 to satisfy And of course the reason Cargo does that is that it knows 0.6.15 may not be linked with 0.7.0.... so it picks 0.6.14 which it believes is allowed. Too clever for its own good in this case! |
@adamgreig I've attempt to fix this for posterity in #603. In the meantime I'll just use 0.6.15, thanks! |
603: Fix allowable cortex-m-rt versions r=adamgreig a=rmsc This should prevent Cargo from pulling in two different versions of cortex-m-rt, as happened in #602. This is done by requiring a cortex-m-rt version >=0.6.15, which was the first version where the `link=cortex-m-rt` field was set in Cargo.toml. ~~The second fix is to clearly allow a cortex-m version >= 0.7.2, but still <0.8. I suspect that cargo would still allow newer versions to resolve version conflicts (as happened in #602), but I think it's better to be explicit about it.~~ EDIT: just realized that the second fix doesn't make sense. Co-authored-by: Renato Caldas <renato@calgera.com>
Could we release all with |
#603 is merged and the next stm32-rs release will include it, along with all the other recent changes. I expect to have 0.14 released soon enough that it doesn't seem worth backporting it to 0.13. |
Thanks! |
If I simultaneously depend on these two:
I get linker errors on the simplest application code:
The text was updated successfully, but these errors were encountered: