Including `minifb` and `log` breaks `no_std` builds

[xobs]

I have a package that uses minifb when building on Windows, and uses raw calls when building on an embedded platform.

However, even including a reference to minifb causes log to fail to build, even if I conditionally require minifb.

src/main.rs:

#![cfg_attr(target_os = "none", no_std)]
#![cfg_attr(target_os = "none", no_main)]

#[cfg(target_os = "none")]
use core::panic::PanicInfo;

#[cfg(target_os = "none")]
#[panic_handler]
fn handle_panic(_arg: &PanicInfo) -> ! {
    loop {}
}

#[cfg(target_os = "none")]
pub fn some_main() -> ! {
    loop {}
}

#[cfg(not(target_os = "none"))]
fn main() {
    loop {}
}

Cargo.toml:

[package]
name = "minifb-build-test"
version = "0.1.0"
authors = ["Sean Cross <sean@xobs.io>"]
edition = "2018"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
log = "0.4"

[target.'cfg(any(windows,unix))'.dependencies]
minifb = "0.19"

Attempting to build for riscv32imac-unknown-none-elf:

[5:14:06 PM] D:/Code/Xous/minifb-build-test> cargo build --target riscv32imac-unknown-none-elf
    Blocking waiting for file lock on package cache
    Updating crates.io index
    Blocking waiting for file lock on package cache
    Blocking waiting for file lock on package cache
  Downloaded nom v6.1.0
  Downloaded wayland-client v0.27.0
  Downloaded wayland-commons v0.27.0
  Downloaded wayland-cursor v0.27.0
  Downloaded wayland-scanner v0.27.0
  Downloaded wayland-protocols v0.27.0
  Downloaded wayland-sys v0.27.0
  Downloaded xcursor v0.3.3
  Downloaded 8 crates (397.4 KB) in 5.16s
    Blocking waiting for file lock on package cache
    Blocking waiting for file lock on build directory
   Compiling log v0.4.14
error[E0463]: can't find crate for `std`
  |
  = note: the `riscv32imac-unknown-none-elf` target may not be installed

error: aborting due to previous error

For more information about this error, try `rustc --explain E0463`.
error: could not compile `log`

To learn more, run the command again with --verbose.
[5:14:42 PM] D:/Code/Xous/minifb-build-test>

If I remove the entry to minifb by commenting it out, it builds just fine:

[5:13:25 PM] D:/Code/Xous/minifb-build-test> cargo build --target riscv32imac-unknown-none-elf
   Compiling log v0.4.14
   Compiling minifb-build-test v0.1.0 (D:\Code\Xous\minifb-build-test)
warning: unused variable: `arg`
 --> src\main.rs:7:17
  |
7 | fn handle_panic(arg: &PanicInfo) -> ! {
  |                 ^^^ help: if this is intentional, prefix it with an underscore: `_arg`
  |
  = note: `#[warn(unused_variables)]` on by default

warning: 1 warning emitted

    Finished dev [unoptimized + debuginfo] target(s) in 0.37s
[5:14:06 PM] D:/Code/Xous/minifb-build-test>

[emoon]

Maybe I'm wrong, but this seems to be more of a Cargo problem than a minifb problem?

[xobs]

@emoon It could be. Right now I'm trying to determine why it is that including minifb causes this to happen, and why it didn't happen before.

It only seems to happen when I enable x11 or wayland as features. For example, this build works just fine:

[package]
authors = ["Sean Cross <sean@xobs.io>"]
edition = "2018"
name = "minifb-build-test"
version = "0.1.0"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
log = "0.4"

[target.'cfg(any(windows, target_os = "macos"))'.dependencies]
minifb = {version = "0.19", default-features = false}

[emoon]

I see. I'm not sure exactly what could cause this to be honest. If you find out why this is and what needs to be changed in (likely) the minifb cargo.toml I would be happy to apply the changes (or even better if you can do a PR)

[xobs]

I'm still not sure if this is a bug in my setup, a bug in cargo, or a bug in minifb. Using Resolver Version 2 does fix the issue, but I don't know if that's the fix or if it's a workaround: https://github.com/rust-lang/cargo/issues/9147

[emoon]

I see. I'm waiting for the replay on your last question and I guess we will see

[xobs]

It looks like this is "as-designed". The correct solution is to use Resolver Version 2 once 1.51 is released.

Thanks for looking into this!