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
Building nom for no_std fails on dependency memchr #1457
Comments
is there another dependency using nom and activating features on it? |
There isn't. There are other dependencies that depend on memchr though. However, removing nom from my deps allows the project to build, implying that the other dependencies with memchr are also not activating When I get a chance I'll try making a minimal project to see if there is some weird interaction with another dependency I have. When running
It sounds like what you're saying, ultimately, is that some other dep could be turning it back on for memchr? |
this looks really weird, and from what you're telling it comes from nom. Could you show the output of |
I also happen same error, this is my output, thanks. |
my rust env is nightly-2021-11-01, my case also a RISC-V target (k210) which will use no_std. my cargo.toml file is
|
could you provide an example project? I tested locally with that: [package]
name = "no_std_test"
version = "0.1.0"
edition = "2021"
[dependencies]
#nom = { version = "7.0.0", default-features = false, features = [] }
nom = { git = "https://github.com/Geal/nom", default-features = false, features = [] }
[profile.dev]
panic = "abort"
[profile.release]
panic = "abort" #![no_main]
#![no_std]
use core::panic::PanicInfo;
fn main() {
let s = "abc";
nom::character::complete::digit0::<_, ()>(s).unwrap();
}
#[panic_handler]
fn panic(_panic: &PanicInfo<'_>) -> ! {
loop {}
} and it builds fine. I tried with rustc 1.57.0-nightly (5ecc8ad84 2021-09-19) and the same target |
Here is my with nom
Without Nom
I'll attempt a minimal project next. |
Here's an example project I just made This has only the parts required for running the hifive revb board, as well as nom. With nom it does not build, and without it does. If you're building yourself, just be sure to use nightly and add the riscv target:
Let me know if this helps |
oh...I change 2018 to 2021, everything is ok. |
@dougli1sqrd you also try it. |
Oh perfect! Thanks @buhe and @Geal for your help! I updated the example project. To make it work here's what I did:
|
Awesome, nice to see there's a fix. But... But why? Why is it fixed by changing the edition? |
Maybe 2.3.x new memchr not compatible 2018 rust? |
I believe that rust 2021 has a new feature resolver that behaves differently? I wonder if we are running into a case that the earlier resolver had a hard time with but fixed with edition 2021. |
Just as an added mystery, I've copied all the dependencies in my original project into my dummy project, and the dummy project still builds which is great! However, trying the steps above - updating to edition 2021 - does not fix my original project build issues. What's so baffling is at this point the dummy project Cargo.toml is identical to the original project, and I even copied all the code. So in one instance it builds and in another it does not. I don't think this is a nom issue, but there's certainly some mysterious build magic happening. |
Ran into exact same issue, even when just trying to use |
Hello there, I'm trying to build nom for a RISC-V target which will use
no_std
. But after adding it to my Cargo.toml rust complained that a dependency requiredstd
.However looking at the previous issues, I found #1370 and saw that there was a fix so I switched my dependency to point directly at github:
However this is still producing:
Looking at the nom Cargo.toml features, it seems like turning off all default features (like I'm doing above) should turn off std in all deps. And it did help, as I fixed the error I was getting in the issue above but I now get an error for memchr.
Any ideas why setting
default-features = false
wouldn't do the trick for memchr?The text was updated successfully, but these errors were encountered: