Linker errors with stm32g4-0.13.0 and cortex-m-rt-0.7.0

[rmsc]

If I simultaneously depend on these two:

[dependencies]
cortex-m-rt = "0.7.0"
stm32g4 = { version = "0.13.0", features = ["stm32g431", "rt"] }

I get linker errors on the simplest application code:

#![no_main]
#![no_std]

use panic_halt as _;
use cortex_m_rt::entry;
use stm32g4::stm32g431 as stm32;

#[entry]
fn main() -> ! {
    let _dp = stm32::Peripherals::take().unwrap();
    loop {}
}

$ cargo build
(...)
  = note: rust-lld: error: undefined symbol: WWDG
          >>> referenced by stm32g4.a536753e-cgu.0
          >>>               stm32g4-0cd8392efc6052b0.stm32g4.a536753e-cgu.0.rcgu.o:(__INTERRUPTS) in archive <redacted>/target/thumbv7em-none-eabihf/debug/deps/libstm32g4-0cd8392efc6052b0.rlib

          rust-lld: error: undefined symbol: PVD_PVM
          >>> referenced by stm32g4.a536753e-cgu.0
          >>>               stm32g4-0cd8392efc6052b0.stm32g4.a536753e-cgu.0.rcgu.o:(__INTERRUPTS) in archive <redacted>/target/thumbv7em-none-eabihf/debug/deps/libstm32g4-0cd8392efc6052b0.rlib

        rust-lld: error: undefined symbol: RTC_TAMP_CSS_LSE
          >>> referenced by stm32g4.a536753e-cgu.0
          >>>               stm32g4-0cd8392efc6052b0.stm32g4.a536753e-cgu.0.rcgu.o:(__INTERRUPTS) in archive <redacted>/target/thumbv7em-none-eabihf/debug/deps/libstm32g4-0cd8392efc6052b0.rlib

(...)

[adamgreig]

The underlying problem is that stm32g4 v0.13 only supports cortex-m-rt v0.6, and that's what it depends on. It's not allowed to combine two versions of cortex-m-rt in a single application, because of the various linker-related things going on with cortex-m-rt.

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 links=cortex-m-rt field in their Cargo.toml, and I don't know why that isn't triggering here.

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.

[rmsc]

Thanks, now I understand. It seems that cortex-m-rt <= 0.6.14 didn't set the links=cortex-m-rt field.

If I set cortex-m-rt = "*" then only version 0.6.15 is pulled, but if I set it to "0.7.0" then I get two versions (0.6.14 and 0.7.0).

[adamgreig]

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 ^0.6.10 in stm32g4 (which, fair enough) so doesn't give you the warning.

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!

[rmsc]

@adamgreig I've attempt to fix this for posterity in #603.

In the meantime I'll just use 0.6.15, thanks!

[David-OConnor]

Could we release all with rmsc's PR merged?

[adamgreig]

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.

[rmsc]

Thanks!