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

extern library not resolved when specifying --cfg rust flag in [target.<cfg>] #11166

Closed
BugenZhao opened this issue Sep 30, 2022 · 3 comments
Closed
Labels
C-bug Category: bug

Comments

@BugenZhao
Copy link

BugenZhao commented Sep 30, 2022

Problem

There are some APIs of tokio requiring a special --cfg tokio_unstable, like the tokio console with the feature tracing. By putting this rustflag in [build] or [target.<triple>] session, it works well. However, when I put the flag in the [target.<cfg>] (like [target.'cfg(all())']), tokio cannot compile.

i.e., this works,

[target.'cfg(all())']
rustflags = [
    "--cfg", "always",
  # "--cfg", "tokio_unstable"
]

[target.aarch64-apple-darwin]
rustflags = [
    "--cfg", "apple",
    "--cfg", "tokio_unstable"
]

but this doesn't.

[target.'cfg(all())']
rustflags = [
    "--cfg", "always",
    "--cfg", "tokio_unstable"
]

[target.aarch64-apple-darwin]
rustflags = [
    "--cfg", "apple",
  # "--cfg", "tokio_unstable"
]

By comparing the cargo check --verbose, I found that the --extern option for tracing passing to rustc is missing. This caused the compiler to fail to resolve the tracing crate.

- --extern tracing=/Users/bugenzhao/Developer/Works/profile-rustflags/target/debug/deps/libtracing-5ca025473bc6506d.rmeta --cap-lints allow --cfg mac --cfg tokio_unstable
+ --cap-lints allow --cfg mac --cfg tokio_unstable
error[E0433]: failed to resolve: use of undeclared crate or module `tracing`
   --> /Users/bugenzhao/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.21.1/src/macros/trace.rs:4:13
    |
4   |             tracing::trace!(
    |             ^^^^^^^ use of undeclared crate or module `tracing`

Steps

  1. Initialize an empty crate.
  2. Add the tokio dependency.
tokio = { version = "*", features = ["full", "tracing"] }
  1. In .cargo/config.toml:
[target.'cfg(all())']
rustflags = [
    "--cfg", "tokio_unstable"
]
  1. Run cargo check --verbose.

Possible Solution(s)

No response

Notes

I've also tried to specify it in the profile.<profile>.rustflags, and it does not work either. :(

Version

cargo 1.64.0-nightly (85b500cca 2022-07-24)
release: 1.64.0-nightly
commit-hash: 85b500ccad8cd0b63995fd94a03ddd4b83f7905b
commit-date: 2022-07-24
host: aarch64-apple-darwin
libgit2: 1.4.2 (sys:0.14.2 vendored)
libcurl: 7.79.1 (sys:0.4.55+curl-7.83.1 system ssl:(SecureTransport) LibreSSL/3.3.6)
os: Mac OS 12.5.0 [64-bit]
@ehuss
Copy link
Contributor

ehuss commented Sep 30, 2022

Hm, I can't seem to reproduce your issue. The "Steps" section contains a different config from the one described at the top. I tried both and they seemed to work. Can you include the entire output from cargo check --verbose? Can you also run cargo config get -Zunstable-options (and remove any sensitive information like token before posting).

@BugenZhao
Copy link
Author

I've retried it and found that it works with nightly-2022-10-01 while not with nightly-2022-07-29. The crate to reproduce and the output of cargo check --verbose is here. The output of cargo config get -Zunstable-options is the same:

target."cfg(all())".rustflags = ["--cfg", "tokio_unstable"]
# The following environment variables may affect the loaded values.
# CARGO_HOME=/Users/bugenzhao/.cargo

So I guess it's #11114 that fixed this issue.

Then I also tried to specify --cfg tokio_unstable in profile rustflags (the diff here), but both of the toolchains don't work. Is this a similar issue to #11114?

@ehuss
Copy link
Contributor

ehuss commented Oct 1, 2022

The issue with profile rustflags is a little different. The profile information is not considered when cargo is determining target settings. I noted that on the profile rustflags tracking issue.

Sounds like #11114 resolved the issue here, so closing as resolved by that.

@ehuss ehuss closed this as not planned Won't fix, can't repro, duplicate, stale Oct 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: bug
Projects
None yet
Development

No branches or pull requests

2 participants