Unknown feature "auto_traits"
coffeenotfound opened this issue · 12 comments
When trying to build uefi-rs I get error[E0635]: unknown feature 'auto_traits' at github.com-1ecc6299db9ec823\uefi-0.7.0\src\lib.rs:27:12.
Looking through the offical list of unstable features it appears it doesn't exist anymore...
Does anyone else have this problem?
(I'm on cargo 1.50.0-nightly (bfca1cd22 2020-11-24))
Hello! Could you try updating to a newer nightly? I've successfully built the latest master using cargo 1.50.0-nightly (d274fcf86 2020-12-07)
Updating seems to have done the trick!
But now rust-lld complains about missing memcpy et al. eventhough I have rlibc in my dependencies which is kinda weird...
In desperation I have also forked and removed the #![feature(auto_traits)] and that also seems to work (I get to the error-ing linkage phase) which makes me wonder: What's the purpose of that attribute?
You're right about the auto_traits, it seems Rust has stabilized enough so we don't need that unstable feature anymore. However, I don't think it's related to the issue you're having.
Is the .cargo/config file in your project similar to the one in this repo?
I seem to have figured out the linkage problem now
My .cargo/config is indeed very similar (the relevant bits like build-std) but even with rlibc I couldn't get it to link because of missing mem functions.
But it seems like rlibc is deprecated anyway and following their guide by enabling the mem feature of compiler-builtins actually fixed it!
My .cargo/config now contains this:
[unstable]
build-std = ["core", "compiler_builtins", "alloc"]
build-std-features = ["compiler-builtins-mem"]
(Note the compiler-builtins-mem feature instead of mem because I don't think we can directly enable features of compiler-builtins and the former just passes it along for us)
I think it would be great to have this in the documentation!
If you want I can add it and open a PR
That would be great! We already have a .cargo/config file, but I guess it should be specified in the BUILDING.md document (or wherever you feel it's more relevant).
One last thing I should note is that my compile output now also includes the following
warning: Patch `addr2line v0.14.0 (C:\Users\<user>\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\src\rust\vendor\addr2line)` was not used in the crate graph.
Patch `adler v0.2.3 (C:\Users\<user>\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\src\rust\vendor\adler)` was not used in the crate graph.
Patch `gimli v0.23.0 (C:\Users\<user>\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\src\rust\vendor\gimli)` was not used in the crate graph.
Patch `miniz_oxide v0.4.0 (C:\Users\<user>\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\src\rust\vendor\miniz_oxide)` was not used in the crate graph.
Patch `object v0.22.0 (C:\Users\<user>\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\src\rust\vendor\object)` was not used in the crate graph.
Check that the patched package version and available features are compatible
with the dependency requirements. If the patch has a different version from
what is locked in the Cargo.lock file, run `cargo update` to use the new
version. This may also occur with an optional dependency that is not enabled.
I'm not entirely sure what that means but it appears to work perfectly anyways.
I've tried searching on google but I haven't really got anything yet. I think this happens because some optional dependency is being configured in the Cargo.toml but then not actually used by the crate (probably because I'm not compiling the full std) but it's hard to say and may just be an overzealous warning...
I'd like to find a solution to this first before merging to master though
Running cargo update does something but doesn't fix it
I've tried building the code locally, and I couldn't reproduce the warnings.
That being said, I am on Ubuntu, and from the output it looks like your using the MinGW toolset on Windows. Maybe the warnings occur due to Rust trying to use the Windows-specific crates with uefi-rs?
I don't think uefi-rs is the problem but rather the standard library.
Looking through it it looks like the crates from the warning have a lot to do with backtrace support with I haven't enabled, so I don't think the warnings are all that relevant
I'll open a PR in the next little while that replaces rlibc with the new approach
Closing this issue (missing feature auto_traits) because it's solved by updating to the latest nightly
And thanks for the support!