globally disabled logs still require symbols on x86 = linker error

[japaric]

This program:

fn main() {
    defmt::info!("hello");
    println!("hello");
}

fails to link if you use defmt v0.2.0

$ cargo r
(..)
  = note: /usr/bin/ld: (..)/target/debug/deps/libdefmt-00ba9b2b47686b1f.rlib(defmt-00ba9b2b47686b1f.defmt.bhjss6u8-cgu.12.rcgu.o): in function `defmt::export::acquire':
          (..)/defmt-0.2.0/src/export.rs:36: undefined reference to `_defmt_acquire'
          /usr/bin/ld: (..)/target/debug/deps/libdefmt-00ba9b2b47686b1f.rlib(defmt-00ba9b2b47686b1f.defmt.bhjss6u8-cgu.12.rcgu.o): in function `defmt::export::release':
          (..)/defmt-0.2.0/src/export.rs:48: undefined reference to `_defmt_release'
          /usr/bin/ld: (..)/target/debug/deps/libdefmt-00ba9b2b47686b1f.rlib(defmt-00ba9b2b47686b1f.defmt.bhjss6u8-cgu.12.rcgu.o): in function `defmt::export::timestamp':
          (..)/defmt-0.2.0/src/export.rs:60: undefined reference to `_defmt_timestamp'
          collect2: error: ld returned 1 exit status

but links and runs fine if you use defmt v0.1.3

$ cargo r
(..)
     Running `target/debug/hello`
hello

note that all logs are disabled in both cases (no Cargo features were added to the crate's Cargo.toml)

[japaric]

git bisect points to PR #291 as the cause of this issue

[japaric]

a user has reported the _defmt_panic symbol is also required when host = x86 windows

[Urhengulas]

I think this issue is solved by #477. @WasabiFan tested it on windows and it also works for me on fedora.

[WasabiFan]

Unfortunately (in addition to having inadvertently introduced breaking changes), this doesn't seem to solve the problem in all cases. To give a sampling:

• My project's normal release build works fine, but building the tests on my Windows box returns the original linker errors
  • Depending on defmt via a local path dependency avoids any error, but depending on it via git or crates.io fails to compile as described above
  • Deleting a few arbitrary modules in my project fixes the error (probably something to do with Microsoft's linker giving up on optimizations if the project is too big? Not clear.)
• Other team members on their own Windows machines cannot reproduce this error (it builds and tests run cleanly for them)
• Linux builds work fine.

So I'm pretty strongly convinced that my fix is not sufficient to be truly dependable.

However, the fact that it can build demonstrates that there isn't much standing in the way of fixing this the "right" way -- I think bounding all four functions which declare external symbols (those containing extern "Rust" ) in src/export.rs with the same feature check as is now used in the macro calls themselves would be sufficient. We wouldn't even have to disable all usages of acquire/release/timestamp/panic, just swap them out with inert versions like the unstable-test feature does.

In my own project I have now (surely inadvisably) enabled the unstable-test feature in my test builds, purely to disable defmt as much as possible. I'll include details on my setup for others' reference below. This is a sufficient stopgap for my purposes.

I think for now this issue should be re-opened and I'd be interested to hear thoughts on adding those additional feature checks to the four functions mentioned above -- i.e., disable any attempt to resolve those symbols when no defmt features are enabled. In that case, building with --no-default-features would ensure that there is no attempt to resolve nonexistent functions. Alternately, a new feature could be added which has this effect when enabled.

---

I added the following to my dev-dependencies:

[dev-dependencies]
defmt = { version = "0.2.2", features = [ "unstable-test" ] }

And adopted the new Cargo feature resolver, so that the feature is not enabled in production builds:

[package]
resolver = "2"

[Urhengulas]

Hi @WasabiFan, Could you reproduce the error on any other windows machine, except yours? And am I understanding it correctly that building the binary works for you, but building the tests fails?