I'm having a hard time cross-compiling an embedded Rust project that worked before for a raspberry pi. I have all the needed deps in Cargo.toml but on doing:
$ cargo build --target thumbv7m-none-eabi
I get the following error.
error[E0463]: can't find crate for `std`
--> /home/.cargo/registry/src/github.com-1ecc6299db9ec823/lazy_static-1.4.0/src/inline_lazy.rs:9:1
|
9 | extern crate std;
| ^^^^^^^^^^^^^^^^^ can't find crate
|
= note: the `thumbv7m-none-eabi` target may not support the standard library
= help: consider building the standard library from source with `cargo build -Zbuild-std`
For more information about this error, try `rustc --explain E0463`.
error: could not compile `lazy_static` due to previous error
$ rustup show
installed targets for active toolchain
--------------------------------------
thumbv7m-none-eabi
x86_64-unknown-linux-gnu
active toolchain
----------------
nightly-x86_64-unknown-linux-gnu (default)
rustc 1.64.0-nightly (38b72154d 2022-07-11)
Compilation used to work previously without lazy_static as a dependency in cargo.toml,now I don't understand why this is happening.
By default lazy_static depends on the rust standard library, which as the compiler told you
may not be supported on the thumbv7m-none-eabi target
If you do not need the standard library in your project you can enable the no-std feature of lazy_static like this:
lazy_static = { version = "1.5.0", features = ["spin_no_std"] }
as described here.
Related
I am new to Rust, so this could be a stupid mistake, but I can't figure out how to fix it.
The problem
I tried to install Inari (a Rust implementation of interval arithmetic, https://crates.io/crates/inari). But when I try to compile the project, I get some errors:
Compiling inari v1.0.0
error: RUSTFLAGS='-Ctarget-cpu=haswell' or later is required. See https://doc.rust-lang.org/rustc/codegen-options/#target-cpu
--> /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/inari-1.0.0/src/simd/x86_64.rs:174:9
|
174 | ... compile_error!("RUSTFLAGS='-Ctarget-cpu=haswell' or later is required. See https://doc.rust-lang.org/rustc/codegen-options/#target-cpu...
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
error[E0425]: cannot find function `add_ru` in this scope
--> /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/inari-1.0.0/src/arith.rs:25:21
|
25 | Self { rep: add_ru(x, y) }
| ^^^^^^ help: a function with a similar name exists: `add_rn`
|
...
The error says something about using Haswell, so I tried to add the following lines to Cargo.toml:
[build]
rustflags = ["-Ctarget-cpu=haswell"]
rustdocflags = ["-Ctarget-cpu=haswell"]
but it didn't change anything.
Steps to reproduce
Create a new project with cargo new project-name. Add inari as a dependancy cargo add inari. Run the project with cargo run.
Environment
cargo 1.62.1 (a748cf5a3 2022-06-08)
rustc 1.62.1 (e092d0b6b 2022-07-16)
Ubuntu 20.04.3 LTS (in WSL)
You need to put that in .cargo/config.toml, not in Cargo.toml. Alternatively, set the environment variable RUSTFLAGS before running Cargo.
See Configuration - build.rustflags - The Cargo Book.
I am trying to cross-compile an example rust code as library for bare-metal AArch64 on Linux (KDE-Neon). Unfortunately it does not work. This is my example rust code (lib.rs):
#![no_std]
#[no_mangle]
pub extern "C" fn double_value (a : u32) -> u32
{
a / 2
}
According to [1] I first installed rustup with:
sudo snap install rustup --classic
Afterwards, I followed [2] and ran:
rustup toolchain list
rustup install stable
rustup default stable
Then I followed [1] and [3] and ran:
rustup target add aarch64-unknown-none
However when I try to compile afterwards, I doesn't work, neither with rustc nor with cargo:
rustc:
rustc --crate-type=lib lib.rs --target=aarch64-unknown-none
error[E0463]: can't find crate for `core`
|
= note: the `aarch64-unknown-none` target may not be installed
error: aborting due to previous error
cargo:
Cargo.toml:
[package]
name = "rust_baremetal_lib"
version = "0.1.0"
edition = "2018"
[lib]
name = "rust_baremetal_lib"
path = "src/lib.rs"
crate-type = ["staticlib"]
[dependencies]
cargo build --lib --target=aarch64-unknown-none
Compiling rust_baremetal_lib v0.1.0 (/home/kilian/code/rust_link/rust_baremetal_lib)
error[E0463]: can't find crate for `core`
|
= note: the `aarch64-unknown-none` 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 `rust_baremetal_lib`
To learn more, run the command again with --verbose.
To me it looks like rustc and cargo cannot find the core library, although it should be installed, as seen when running rustc --print:
rustc --print target-list|grep arch64-unknown-none
aarch64-unknown-none
aarch64-unknown-none-softfloat
I already looked on the internet but didn't find any clues unfortunately. I hope someone can help me find the issue!
[1] https://rust-lang.github.io/rustup/cross-compilation.html
[2] No default toolchain configured after installing rustup
[3] https://doc.rust-lang.org/nightly/rustc/platform-support.html
The problem seemed to result from a broken rust installation. I removed all packages related to rust that I could found via apt and snap. Afterwards I reinstalled rust via the recommended way [1]. Then I again ran:
rustup target add aarch64-unknown-none
Afterwards Cargo complained, that a "panic handler" was missing in my example code, so I inserted one, following [2]. My example code now looks like this:
#![no_std]
use core::{
panic::PanicInfo,
};
#[no_mangle]
pub extern "C" fn double_value (a : u32) -> u32
{
a * 2
}
#[panic_handler]
fn panic(_info: &PanicInfo) -> ! {
loop {
continue;
}
}
Finally I can now cross-compile this example to an AArch64 bare metal static library with:
cargo build --lib --target=aarch64-unknown-none
[1] https://www.rust-lang.org/tools/install
[2] https://interrupt.memfault.com/blog/zero-to-main-rust-1
I start with the cargo new tst. Then in the src/lib.rs I have:
pub struct Config {}
And src/main.rs looks like the following:
use crate::Config;
fn main() {}
This however does not compile:
> cargo run
Compiling tst v0.1.0 (/home/*/rust/book/tst)
error[E0432]: unresolved import `crate::Config`
--> src/main.rs:1:5
|
1 | use crate::Config;
| ^^^^^^^^^^^^^ no `Config` in the root
For more information about this error, try `rustc --explain E0432`.
error: could not compile `tst` due to previous error
But if I replace crate:: with the name of the crate like so:
use tst::Config;
fn main() {}
Then it just work:
> cargo run
Compiling tst v0.1.0 (/home/*/rust/book/tst)
warning: unused import: `tst::Config`
--> src/main.rs:1:5
|
1 | use tst::Config;
| ^^^^^^^^^^^
|
= note: `#[warn(unused_imports)]` on by default
warning: `tst` (bin "tst") generated 1 warning
Finished dev [unoptimized + debuginfo] target(s) in 0.25s
Running `target/debug/tst`
The output for rustc --explain E0432 has the following quote, which if I understand it correctly means, that I can either use the name of a crate or simply crate:::
In Rust 2018, paths in use statements are relative to the current module
unless they begin with the name of a crate or a literal crate::, in which
case they start from the crate root. As in Rust 2015 code, the self:: and
super:: prefixes refer to the current and parent modules respectively.
Am I doing something wrong in here? Is there a way to use code from lib.rs without hardcoding the name of the crate?
> rustc --version
rustc 1.56.1 (Arch Linux rust 1:1.56.1-3)
> cat Cargo.toml
[package]
name = "tst"
version = "0.1.0"
edition = "2021"
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
[dependencies]
There is no way to refer to “the library crate in my package”; you must refer to it by its name. The Rust compiler doesn't (currently) know anything about other crates that happen to be in the same Cargo package; it just compiles one crate at a time.
In order for this to change, you would need to write a Rust RFC, which would need to include a description of why it would be valuable to have this feature — probably a stronger argument than “it would be less hardcoded”, since main depending on the library is almost certainly going to use library-specific names anyway, so the name of the library itself is a minor issue (unless, I suppose, you're creating many packages from a common template).
I am trying to create an embed-friendly executable (small footprint and without dependency on the Rust standard library) that uses a library (wasmi) that already has support for a no_std build. New to Rust, I am simply piecing together instructions, but the gist of it appears to be follow the steps.
For the executable:
#![no_std]
#![no_main]
use core::panic::PanicInfo;
/// This function is called on panic.
#[panic_handler]
fn panic(_info: &PanicInfo) -> ! {
loop {}
}
#[no_mangle]
pub extern "C" fn _start(_argc: isize, _argv: *const *const u8) -> ! {
interpret(_argc, _argv);
loop {}
}
That is to:
include #![no_std]
define our entry (not main since we don't have a runtime that will call it)
and define a panic handler since the Rust std lib is not included to define it for us.
My Cargo file to compile this looks like this:
[package]
name = "driver"
version = "0.1.0"
edition = "2018"
[dependencies.wasmi]
path = "../../github_dev/wasmi"
features = ["core"]
default-features = false
test=false
bench=false
[profile.release]
panic = "abort"
lto = true
incremental=false
debug=true
opt-level = "z"
test=false
bench=false
and produces a very small binary that excludes any standard library symbols (using nm to check) and runs as expected.
The problem occurs when I actually try to call a function from the wasmi library. It is built with no_std via the features=core line. Doing an nm on the files in release/deps/libwasmi-*.rlib shows no standard library symbols. However when linking occurs with this command:
rustc --release --verbose -- -C link-arg=-nostartfiles
it leads to:
Compiling driver v0.1.0 (/home/my_home/wasmi_embed/driver)
Running rustc --edition=2018 --crate-name driver src/main.rs --color always --crate-type bin --emit=dep-info,link -C opt-level=3 -C panic=abort -C lto -C link-arg=-nostartfiles -C metadata=957eda2e590447ba -C extra-filename=-957eda2e590447ba --out-dir /home/my_home/wasmi_embed/driver/target/release/deps -L dependency=/home/my_home/wasmi_embed/driver/target/release/deps --extern libc=/home/my_home/wasmi_embed/driver/target/release/deps/liblibc-f7fb773c7b059a14.rlib --extern wasmi=/home/my_home/wasmi_embed/driver/target/release/deps/libwasmi-534aef1926b4eb6c.rlib
and an error occurs:
error[E0152]: duplicate lang item found: panic_impl.
--> src/main.rs:31:1
|
31 | / pub extern fn panic(_info: &PanicInfo) -> ! {
32 | | loop {}
33 | | }
| |_^
|
= note: first defined in crate `std`.
It seems Rust is trying to link in standard library support for at least panic handling, but I don't know why.
I would like help to understand why and to understand how to prevent it.
If I remove the panic_impl attribute then my executable compiles, but it includes a lot of standard library symbols that I am trying to prevent.
The example symbols I see are:
my_home#my_puter:~/wasmi_embed/driver/target/release$ nm --demangle -A -a -B -s --line-number test_2018 2>/dev/null | grep std
driver:00000000000264c0 t rust_begin_unwind /rustc/8e2063d02062ee9f088274690a97826333847e17//src/libstd/panicking.rs:311
driver:00000000000264a0 t rust_oom /rustc/8e2063d02062ee9f088274690a97826333847e17//src/libstd/alloc.rs:203
driver:000000000001f490 t rust_panic /rustc/8e2063d02062ee9f088274690a97826333847e17//src/libstd/panicking.rs:524
driver:0000000000025aa0 t _$LT$std..panicking..continue_panic_fmt..PanicPayload$LT$$u27$a$GT$$u20$as$u20$core..panic..BoxMeUp$GT$::get::he4f810e299a2e0b4 /rustc/8e2063d02062ee9f088274690a97826333847e17//src/libstd/panicking.rs:372
driver:00000000000259a0 t _$LT$std..panicking..continue_panic_fmt..PanicPayload$LT$$u27$a$GT$$u20$as$u20$core..panic..BoxMeUp$GT$::box_me_up::hd8430725259668a8 /rustc/8e2063d02062ee9f088274690a97826333847e17//src/libstd/panicking.rs:367
driver:0000000000021520 t _$LT$std..sys_common..process..DefaultEnvKey$u20$as$u20$core..borrow..Borrow$LT$std..ffi..os_str..OsStr$GT$$GT$::borrow::hbacd0cd7d7fbf1c1/rustc/8e2063d02062ee9f088274690a97826333847e17//src/libstd/sys_common/process.rs:27
driver:0000000000021570 t _$LT$std..error..$LT$impl$u20$core..convert..From$LT$alloc..string..String$GT$$u20$for$u20$alloc..boxed..Box$LT$$LP$dyn$u20$std..error..Err
... plus more
The above symbols are not found in any of the rlib files under the dep directory including libwasmi, nor are they found in the driver executable when not calling libwasmi code.
I've read a similar issue (hence my test=false and bench=false in the Cargo.toml) but that did not help. I've tried to build with just rustc with varying commands (excluding Cargo) but the error is the same. I've tried to compile wasmi as a static library (ar) and link it in, but being new to Rust I was spending a lot of time trying to link it in and it just wasn't happening.
I resolved this after seeking some help in the rust forums. enter link description here. Specifically, was not able to determine what was responsible for rust std lib being linked into my executable ... was it an issue with a crate or an issue with cargo or an issue with rustc or an issue with the linker. I did not know where the problem was born, but based on similar bugs filed I figured that somehow a crate was being compiled to bring in std lib unexpected. Turns out bug enter link description here was not related even though the error message was the same. I did not have an issue with unexpected propagations form different type of dependencies (dev-dependencies and build-dependencies). I tried all these techniques to pinpoint what was bringing in std lib:
I tried using cargo tree to list dependencies to list all the crate
dependencies:
wasmi v0.4.3 (/home/jlb6740/github_dev/wasmi)
├── byteorder v1.3.1 (/home/jlb6740/github_dev/byteorder)
├── hashbrown v0.1.8 (/home/jlb6740/github_dev/hashbrown)
│ ├── byteorder v1.3.1 (/home/jlb6740/github_dev/byteorder) ()
│ └── scopeguard v0.3.3 (/home/jlb6740/github_dev/scopeguard)
├── libm v0.1.2
├── memory_units v0.3.0
└── parity-wasm v0.31.0 (/home/jlb6740/github_dev/parity-wasm)
└── byteorder v1.3.1 (/home/jlb6740/github_dev/byteorder) ()
I tried using cargo rustc --verbose … but at this time verbose does
not indicate anything was using default features which may include
using std
I tried using cargo metadata … this generated a long list of
dependencies that was hard to parse, but I did see some instances
where scopeguard and byteorder had default features requiring std
support. I downloaded all of these crates and just hardcoded
attributes so that the crates would only build with no_std support.
I tried looking at the deps/ output and did an nm on all of the
rlibs to see if any of the libraries used symbols found in std. I
could not find that that was the case. I thought rlibs were like
static libraries and that anything they used would be included in
the rlib but apparently not.
I looked at cargo rustc -- -C --print-link-args to check out linker
flags but I could not find anything obvious telling me it was
bringing in std lib.
None of these things helped me to pinpoint what was introducing std lib. Ultimately the suggestion at the rust forums was to use cargo check for a target that does not allow std lib at all. Those with a * listed here: enter link description here have only core support. I tried that, running with --target=thumbv7m-none-eabi and saw:
error[E0463]: can’t find crate for alloc
–> /home/jlb6740/github_dev/hashbrown/src/lib.rs:44:1
|
44 | extern crate std as alloc;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^ can’t find crate
Turns out it was hashbrown which was a dependency of a dependency of my executable. It built no_std by default but had an extern std linked under a different name and which was guarded by a feature called “nightly”. The guard was disabled in my efforts to not build anything but no_std. Nothing I’d tried alerted me to the crate which was responsible until this. Seems there should be a better way to get a more comprehensive list of crate dependencies than what cargo tree provided, but changing the wasmi cargo to make sure the nightly feature was set solved my issue.
$ cargo build
Downloading pear_codegen v0.0.16
Compiling pear_codegen v0.0.16
Compiling ring v0.11.0
error[E0023]: this pattern has 1 field, but the corresponding tuple variant has 2 fields
--> /.cargo/registry/src/github.com-1ecc6299db9ec823/pear_codegen-0.0.16/src/lib.rs:317:9
|
317 | ExprKind::Block(block) => {
| ^^^^^^^^^^^^^^^^^^^^^^ expected 2 fields, found 1
error: aborting due to previous error
For more information about this error, try `rustc --explain E0023`.
error: Could not compile `pear_codegen`.
warning: build failed, waiting for other jobs to finish...
error: build failed
When I try to compile my project I get an error that a crate that isn't in my cargo.toml is broken. Why is this unrelated crate breaking my project?
You're using Rust nightly, and the crate in question used to depend (in version 0.0.16) on the perma-unstable API of the Rust compiler, which was changed by a nightly you updated to (or just installed).
The author appears to have recently rewritten the crate to avoid that dependency, which means further breakage should be avoided, starting with version 0.0.17 of the crate.
cargo update
fixed the issue for me
https://github.com/SergioBenitez/Pear/issues/7
thanks to reddit user /u/usernamedottxt