While beginning my work on CS140e today I've completed phase 3 of the project (writing C code to speak directly to GPIO pins on a Raspberry Pi 3 which would simply blink an LED) but on phase 4, once I attempt to compile my solution in Rust, rustc seems to not be able to find the aarch64-none-elf target:
➜ phase4 git:(master) ✗ make
+ Building target/aarch64-none-elf/release/libblinky.a [xargo --release]
WARNING: the sysroot can't be built for the Stable channel. Switch to nightly.
warning: `panic` setting is ignored for `test` profile
Compiling rlibc v1.0.0
error[E0463]: can't find crate for `core`
|
= note: the `aarch64-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 `rlibc`.
To learn more, run the command again with --verbose.
Makefile:35: recipe for target 'target/aarch64-none-elf/release/libblinky.a' failed
make: *** [target/aarch64-none-elf/release/libblinky.a] Error 101
and, indeed, rustc --print target-list doesn't include aarch64-none-elf:
➜ phase4 git:(master) ✗ rustc --print target-list
aarch64-linux-android
aarch64-unknown-cloudabi
aarch64-unknown-freebsd
aarch64-unknown-fuchsia
aarch64-unknown-linux-gnu
aarch64-unknown-linux-musl
aarch64-unknown-openbsd
...
Though I have installed the toolchain:
➜ phase4 git:(master) ✗ whereis aarch64-none-elf-gcc
aarch64-none-elf-gcc: /usr/local/bin/aarch64-none-elf/bin/aarch64-none-elf-gcc
Also, I have a custom target file named aarch64-none-elf.json with these contents (presumably passed to xargo when building):
{
"abi-blacklist": [
"stdcall",
"fastcall",
"vectorcall",
"thiscall",
"win64",
"sysv64"
],
"arch": "aarch64",
"data-layout": "e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128",
"executables": true,
"linker": "aarch64-none-elf-ld",
"linker-flavor": "ld",
"linker-is-gnu": true,
"llvm-target": "aarch64-unknown-none",
"no-compiler-rt": true,
"features": "+a53,+strict-align",
"max-atomic-width": 128,
"os": "none",
"panic": "abort",
"panic-strategy": "abort",
"position-independent-executables": true,
"target-c-int-width": "32",
"target-endian": "little",
"target-pointer-width": "64",
"disable-redzone": true
}
Turns out all I needed to do was run rustup default nightly and use the nightly version of rustc, as mentioned in the warning and I'm able to get past that error. If anyone want's to explain why this is, that'd be nice.
➜ phase4 git:(master) ✗ rustc --version
rustc 1.30.0-nightly (33b923fd4 2018-08-18)
Related
I'm trying to follow the steps explained in Embeddonomicon to compile the smallest #![no-std] program, but for a new target on a new architecture.
The architecture is upstreamed in LLVM as an experimental target ("ARC") but its not used by rustc, so first I enabled it in the LLVM that comes with Rust as explained here: run ./x.py setup then update the config.toml:
[llvm]
download-ci-llvm = false
ninja = true
targets = "X86"
experimental-targets = "ARC"
Then I manually added the support for the arch following the steps explained here (using this commit as an example):
created rustc_target/src/abi/call/arc.rs
updated rustc_llvm/src/lib.rs
etc
Then I added the target file arc-pc-unknown-gnu.json and made it visible through RUST_TARGET_PATH envvar:
{
"arch": "arc",
"cpu": "generic",
"abi": "eabi",
"c-enum-min-bits": 8,
"data-layout": "e-m:e-p:32:32-i64:32-f64:32-v64:32-v128:32-a:0:32-n32",
"eh-frame-header": false,
"emit-debug-gdb-scripts": false,
"executables": true,
"features": "",
"linker": "rust-lld",
"linker-flavor": "ld.lld",
"llvm-target": "arc-pc-unknown-gnu",
"max-atomic-width": 32,
"atomic-cas": false,
"panic-strategy": "abort",
"relocation-model": "static",
"target-pointer-width": "32"
}
Built the compiler: ./x.py build -i --target=arc-pc-unknown-gnu library/core. It finished successfully, I could see stage1 libs for the arc-pc-unknown-gnu target
I thought this would be enough, but the code was not compiling because of the following issues:
$ rustc --emit=llvm-ir -o rust_main.ll -C panic=abort --target arc-pc-unknown-gnu src/main.rs
error[E0463]: can't find crate for `core`
|
= note: the `arc-pc-unknown-gnu` target may not be installed
= help: consider downloading the target with `rustup target add arc-pc-unknown-gnu`
= help: consider building the standard library from source with `cargo build -Zbuild-std`
error[E0463]: can't find crate for `compiler_builtins`
error[E0412]: cannot find type `PanicInfo` in this scope
--> src/main.rs:18:18
This is weird because on the previous step I should have compiled these very libs for my target...
Then I though that perhaps I needed to rebuild libcore again using cargo build-std (although I don't know why exactly, but someone on the web mentioned this)? I tried this, but now there are the following errors:
$ cargo build -Z build-std=core --target arc-pc-unknown-gnu
Compiling compiler_builtins v0.1.70
Compiling core v0.0.0 (/home/valeriyk/proj/rust-arc/1.60.0/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/src/rust/library/core)
error[E0463]: can't find crate for `std`
error: cannot find macro `println` in this scope
--> /home/valeriyk/.cargo/registry/src/github.com-1ecc6299db9ec823/compiler_builtins-0.1.70/build.rs:88:9
|
88 | println!("cargo:rustc-cfg=kernel_user_helpers")
| ^^^^^^^
error: cannot find macro `println` in this scope
--> /home/valeriyk/.cargo/registry/src/github.com-1ecc6299db9ec823/compiler_builtins-0.1.70/build.rs:78:9
|
78 | println!("cargo:rustc-cfg=thumb_1")
| ^^^^^^^
...
How come that libcore needs std? I just want to have it cross-compiled using the stage1 rustc, and then picked up during my #![no_std] example compilation. Any guidance is appreciated.
That's how I solved the issue:
Use the right rustc source code. I started with a stable version whose libcore was not compatible with the latest compiler_builtins. See here for more details. Then I needed to upgrade to the latest nightly.
When building the compiler, don't ask to build libcore for the final stage, instead build rustc only:
$ ./x.py build -i --stage=1 --target=arcv2-none-elf32 compiler/rustc
Use the following for the .cargo/config.toml, don't use Xargo or -Z build-std=core. The compiler-builtins-mem thing is explained here.
[unstable]
build-std = [
"core",
"compiler_builtins"
]
build-std-features = ["compiler-builtins-mem"]
[build]
target = "arcv2-none-elf32"
Build the code with a simple cargo build. It compiled just fine, although it failed at linking later - but that's another story.
I try to use binutils commands for binary of custom build target with cargo xbuild command.
However, I get an error like below message.
$ cargo nm --target i586-rust_dos.json --bin rust_dos --verbose
"cargo" "build" "--target" "i586-rust_dos.json" "--bin" "rust_dos" "--message-format=json"
Compiling rust_dos v0.1.0 (/home/soya/Documents/src/rust/prac/rust_dos)
error[E0463]: can't find crate for `core` ] 0/2
|
= note: the `i586-rust_dos-8410465322435951119` 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_dos`.
To learn more, run the command again with --verbose.
error: Failed to parse crate metadata
I realized that cargo nm uses cargo build command,
so I think this error should be solved if I make cargo nm to use cargo xbuild instead of cargo build.
However, I cannot find how to do that.
Please teach me if there is a way.
To detect core crate built with cargo xbuild, I need to add sysroot flag in rustflags in .cargo/config.
example is below.
rustflags = ["--sysroot", "/full/path/to/sysroot/directory"]
There is sysroot directory in project's target directory.
If adding these flags, cargo-bintuils commands are enabled to use as far as in my environment.
I am very new to this language and coding field. Beginner to coding field as well.
I tried to build and release file but getting an error Compiling libc v0.2.62
error: Could not compile `libc`
pi#raspberrypi:~/Ganesh_Rust/Real_time/led_blink/src $ cargo run
Finished dev [unoptimized + debuginfo] target(s) in 0.09s
Running `/home/pi/Ganesh_Rust/Real_time/led_blink/target/debug/led_blink`
pi#raspberrypi:~/Ganesh_Rust/Real_time/led_blink/src $ cargo build --release
Compiling libc v0.2.62
error: Could not compile `libc`.
Caused by:
process didn't exit successfully: `rustc --crate-name build_script_build /home/pi/.cargo/registry/src/github.com-1ecc6299db9ec823/libc-0.2.62/build.rs --color always --crate-type bin --emit=dep-info,link -C opt-level=3 --cfg 'feature="default"' --cfg 'feature="std"' -C metadata=b79e3ef31fa8c249 -C extra-filename=-b79e3ef31fa8c249 --out-dir /home/pi/Ganesh_Rust/Real_time/led_blink/target/release/build/libc-b79e3ef31fa8c249 -L dependency=/home/pi/Ganesh_Rust/Real_time/led_blink/target/release/deps --cap-lints allow` (signal: 11, SIGSEGV: invalid memory reference)
code: this program which i wrote in VS code to blink LED on raspberry pi 3
use rust_gpiozero::*;
use std::thread;
use std::time::Duration;
fn main() {
//create a new LEd attached to pin 17 of raspberry pi
let led = LED::new(17);
//blink the led 5 times
for _ in 0.. 5{
led.on();
thread::sleep(Duration::from_secs(10));
led.off();
thread::sleep(Duration::from_secs(10));
}
}
cargo.toml file:
[package]
name = "led_blink"
version = "0.1.0"
authors = ["pi"]
edition = "2018"
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
[dependencies]
rust_gpiozero = "0.2.0"
I am getting output on Raspberry pi but executable file and binary files are large (5MB). So i thought if i do release maybe i can reduce size so tried to release using cargo build --release command but getting this error.
If you're using rustup-provided binaries, then this is a known issue upstream. There is a workaround in that issue, which is to set the following in Cargo.toml:
[profile.release]
codegen-units = 1
As an alternative, you can use the Debian rustc and cargo packages instead of rustup, which should work just fine. You can either download the packages from https://packages.debian.org/rustc and https://packages.debian.org/cargo, or you can add an appropriate APT line into /etc/sources.list (see https://deb.debian.org/ for an example). Note that Debian does not always have the latest version, but they should work.
Summary
I'm fairly new to Rust and decided to use it to port an existing project into it. I intended to use clap to handle CLI options, but I keep getting errors.
What do I need to do for clap to install correctly so that it's usable in my project as a dependency (e.g. extern crate clap; [...] use clap::App; [...]?
I haven't had problems with other crates (so far), so I'm not sure what's so different here or if there's a problem with the crate itself.
I've already seen a few questions (e.g. this one), which simply suggests that the dependency be added into the .toml file or don't seem to provide a solution to what I'm seeing.
I'm in Ubuntu Linux, if that makes a difference.
What I Tried
Adding clap = "2.33.0" to my Cargo.toml file (see https://crates.io/crates/clap) causes VSCode (through RLS) to log the following:
{
"resource": "[...]/Projects/takeout/Cargo.toml",
"owner": "rust",
"severity": 8,
"message": "Could not compile `clap`.\nprocess didn't exit successfully: `[...]/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/rls --crate-name clap [...]/.cargo/registry/src/github.com-1ecc6299db9ec823/clap-2.33.0/src/lib.rs --color never --crate-type lib --emit=dep-info,metadata -C debuginfo=2 --cfg 'feature=\"ansi_term\"' --cfg 'feature=\"atty\"' --cfg 'feature=\"color\"' --cfg 'feature=\"default\"' --cfg 'feature=\"strsim\"' --cfg 'feature=\"suggestions\"' --cfg 'feature=\"vec_map\"' -C metadata=630980a214d5fd10 -C extra-filename=-630980a214d5fd10 --out-dir [...]/Projects/takeout/target/rls/debug/deps -L dependency=[...]/Projects/takeout/target/rls/debug/deps --extern ansi_term=[...]/Projects/takeout/target/rls/debug/deps/libansi_term-1510a9addefc0253.rmeta --extern atty=[...]/Projects/takeout/target/rls/debug/deps/libatty-7c4847fd9fc1e3d9.rmeta --extern bitflags=[...]/Projects/takeout/target/rls/debug/deps/libbitflags-8369a9aec15a5abb.rmeta --extern strsim=[...]/Projects/takeout/target/rls/debug/deps/libstrsim-301d1cf239e9cd24.rmeta --extern textwrap=[...]/Projects/takeout/target/rls/debug/deps/libtextwrap-a799d71e2d028df4.rmeta --extern unicode_width=[...]/Projects/takeout/target/rls/debug/deps/libunicode_width-58e38dd9d658dcfb.rmeta --extern vec_map=[...]/Projects/takeout/target/rls/debug/deps/libvec_map-4f8e59c92e9953d8.rmeta --cap-lints allow --error-format=json --sysroot [...]/.rustup/toolchains/stable-x86_64-unknown-linux-gnu` (exit code: 101)",
"startLineNumber": 1,
"startColumn": 1,
"endLineNumber": 10000,
"endColumn": 1
}
According to the README in the clap repo itself, just adding it should work:
For full usage, add clap as a dependency in your Cargo.toml to use from crates.io:
[dependencies]
clap = "~2.33"
But it doesn't.
I've tried it with and without the ~ prefix as well as clap = {version = "2.33", features = ["yaml"]}, which is also shown in the repo, but no luck. (Yes, I'm trying to load the CLI options from a .yaml file.)
Trying cargo install clap --version 2.33.0 from the shell simply returns an error message saying: error: specified package has no binaries.
Aiming directly at the Git repo also produces the same error message:
cargo install --git https://github.com/clap-rs/clap.git --tag v2.31.2 --features yaml 101 ↵
Updating git repository `https://github.com/clap-rs/clap.git`
Installing clap v2.31.2 (https://github.com/clap-rs/clap.git?tag=v2.31.2#07c15d28)
error: specified package has no binaries
Note that there's no v2.33.0 tag in the Git repo (at the time of this writing).
Bonus if you know how to get VSCode to stop marking everything as an error:
cargo install
There's misunderstanding about the cargo install command. You can learn more about it here.
This command manages Cargo’s local set of installed binary crates. Only packages which have executable [[bin]] or [[example]] targets can be installed, and all executables are installed into the installation root’s bin folder.
It's not your case. The only thing you have to do is to list clap in the dependencies section (Cargo.toml). That's all. No need to use cargo install at all. cargo build, cargo run, ... commands will download & compile & statically link all dependencies.
An example
Folder structure:
.
├── Cargo.toml
└── src
├── cli.yaml
└── main.rs
Current directory:
$ pwd
/Users/robertvojta/Projects/stackoverflow/clap-yaml
Cargo.toml content:
[package]
name = "clap-yaml"
version = "0.1.0"
authors = ["Zrzka"]
edition = "2018"
[dependencies]
clap = { version = "2.33.0", features = ["yaml"] }
src/cli.yaml content:
name: clap-yaml
version: "1.0"
author: Zrzka
about: Stackoverflow sample
args:
- lang:
short: l
long: lang
default_value: cz
takes_value: true
possible_values:
- cz
- en
src/main.rs content:
use clap::{App, load_yaml};
fn main() {
let yaml = load_yaml!("cli.yaml");
let matches = App::from_yaml(yaml).get_matches();
match matches.value_of("lang").unwrap() {
"cz" => println!("Ahoj"),
"en" => println!("Hello"),
_ => unreachable!("see possible_values in yaml, handled by clap"),
};
}
Run it with cargo:
$ cargo -q run -- --lang en
Hello
Run it directly:
$ cargo build
...
Finished dev [unoptimized + debuginfo] target(s) in 0.01s
$ target/debug/clap-yaml --lang cz
Ahoj
Visual Studio Code
I still have vscode complaining and underlining everything in red in the Cargo.toml file. Any suggestions to fix this completely? It seems close to a full resolution.
I can confirm that this problem do exist in Rust 1.34.0. I did install this version and I've got same symptoms:
could not compile clap
the whole Cargo.toml is underlined (error)
There're two ways how to fix this.
Update your Cargo.toml file dependencies section manually if you'd like to stick with Rust 1.34.0:
[dependencies]
bitflags = "=1.0.4"
clap = { version = "2.33.0", features = ["yaml"] }
Or update your Rust toolchain to >= 1.35.0.
I just tested both ways and it works.
Related issues:
Could not compile clap. process didn't exit successfully
Compiler panics on latest RLS when compiling crates that depend on bitflags 1.0.5
My project depends on the ffmpeg-sys crate which is configured to build statically, as follows:
[dependencies.ffmpeg-sys]
version = "3.4.1"
default-features = false
features = ["avcodec", "avformat", "swresample", "build", "static"]
My project consists of a single simple file:
extern crate ffmpeg_sys;
use ffmpeg_sys::av_register_all;
fn main() {
unsafe { av_register_all() };
println!("Hello, world!");
}
When compiling with cargo build I get the following error:
Compiling sample v0.1.0 (file:///home/ec2-user/sample)
error: linking with 'cc' failed: exit code: 1 | = note: "cc"
"-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L"
[... elided for clarity ...]
In function 'sample::main::hbbb19855251826d6':
/home/ec2-user/sample/src/main.rs:6: undefined reference to 'av_register_all'
collect2: error: ld returned 1 exit status
The required static libraries, libavformat.a and friends, are found in the target/build/debug folder, showing that ffmpeg-sys successfully compiled the libraries.
Here's the rustc command that is failing:
Caused by: process didn't exit successfully: 'rustc --crate-name
sample src/main.rs --crate-type bin --emit=dep-info,link -C
debuginfo=2 -C metadata=250bf40eb277d05a -C
extra-filename=-250bf40eb277d05a --out-dir
/home/ec2-user/sample/target/debug/deps -C
incremental=/home/ec2-user/sample/target/debug/incremental -L
dependency=/home/ec2-user/sample/target/debug/deps --extern
ffmpeg_sys=/home/ec2-user/sample/target/debug/deps/libffmpeg_sys-fa3ff87f80f2d27e.rlib
-L native=/home/ec2-user/sample/target/debug/build/ffmpeg-sys-0b3c813f29a9a20e/out/dist/lib'
(exit code: 1)
libffmpeg_sys-fa3ff87f80f2d27e.rlib is 207M and I assume therefore contains all the statically compiled ffmpeg code.
This only happens when I build on an Amazon Linux instance. Compiling on my regular Fedora 28 desktop results in a working binary.
How would I go about figuring out the root cause of this error?
I solved this problem by building llvm 6.0.1 and then rebuilding with LIBCLANG_PATH set to point to the newer version.
It would appear that rustc has a minimum version requirement on libclang.so, but I could not find an official source documenting that. The version installed on amazon-linux is 3.6.2 which is evidently too old.