Why does clap fail to compile when added to Cargo.toml? - rust

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

Related

How to cross compile Rust code from Intel Mac to M1 Mac by Zig?

These days I'm curious about the cross-compile in Rust.As I know, it's very simple to do the same thing in Go or Zig.But in Rust, it's very difficult.I write Rust code in my Intel MacBook Pro, want to cross compile to get the executable file which could be run in M1 MacBook Pro. I take some tries and get some errors in linker.
Here is what I have tried.
I install Rust tool and Zig following the official instruction.
$ rustc --version
rustc 1.65.0 (897e37553 2022-11-02)
$
$ zig version
0.10.0-dev.4560+828735ac0
And my rust project structure is just like this:
hello-world -----
|--- .cargo--
|-- config.toml
|--- src-----
|-- main.rs
Cargo.toml
zig
And there are some files look like:
// main.rs
fn main() {
println!("hello world")
}
// config.toml
[target.aarch64-apple-darwin]
rustflags = ["-C", "linker-flavor=ld", "-C", "link-self-contained=no", "-C", "link-arg=-L/usr/local/opt/libiconv/lib"]
linker = "./zig"
// Cargo.toml
[package]
name = "hello-world"
version = "0.1.0"
edition = "2021"
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
[dependencies]
#[profile.release]
#lto=true
// zig
#!/usr/bin/env zsh
zig cc -target aarch64-macos-none $#
And I install libiconv by brew:
$ brew install libiconv
it puts libiconv in directory /usr/local/opt/libiconv/lib
$ ls /usr/local/opt/libiconv/lib
libcharset.1.dylib libcharset.a libcharset.dylib libiconv.2.dylib libiconv.a libiconv.dylib
I install target aarch64-apple-darwin by rustup and could see:
$ rustup show
Default host: x86_64-apple-darwin
rustup home: /Users/<my name>/.rustup
installed targets for active toolchain
--------------------------------------
aarch64-apple-darwin
x86_64-apple-darwin
x86_64-unknown-linux-gnu
x86_64-unknown-linux-musl
active toolchain
----------------
stable-x86_64-apple-darwin (default)
rustc 1.65.0 (897e37553 2022-11-02)
then I start to build in hello-world directory:
$ CC=./zig cargo build --target aarch64-apple-darwin
...
...
note: error(link): mismatched cpu architecture: expected aarch64, found x86_64
error: MismatchedCpuArchitecture
I find some solutions from stackoverflow, it said I can use macOS sdk to cross-compile.
But I think there are more than one method to finish cross-compile, and really want to know how to solve it using zig.
By the way,I just know the basic steps of assembly, not in details, I don't have experience in linking.
Could anyone give me some suggestions ?
Any answer will be appreciated.
This might not be enough to solve your problem fully, but you need at the very least to pass the cross-compilation flags to Zig, and you also need to use the cc subcommand.
Note also that Zig uses macos instead of darwin.
So you need to set CC="./zig cc -target aarch64-macos", that said, I'm not sure if Rust supports spaces in the CC command now (at least a while ago it did not). If it doesn't you will need to wrap everything in a bash script (zcc.sh):
#!/bin/sh
ZIG_LOCAL_CACHE_DIR="$HOME/tmp" zig cc -target aarch64-macos $#
And then CC=./zcc.sh
Note also that the same will need to be done for zig c++ if you also depend on C++ code. The env variable to set in that case is CXX.
Here you can find somebody doing this to build wasmtime:
https://actually.fyi/posts/zig-makes-rust-cross-compilation-just-work/
Finally, you can probably save yourself all this trouble simply by using cargo-zigbuild:
https://github.com/rust-cross/cargo-zigbuild

Is it possible to run a single rust file as a script while linking to other libraries without generating cargo projects

I'd like to run a one off rust "script" without going through creating a cargo project for a single run (since I am providing this script to colleagues).
Ideally I could build directly with the command line avoiding creating cargo projects etc.
for instance:
use serde_json::Value;
use some_private_packege_i_own_locally_in_another_directory;
fn main() {
// do some stuff with these packages and die
}
I would need to depend on the serde_json and my some_private_packege_i_own_locally_in_another_directory.
(A bit similar to rust playground I suppose for a single time use)
Something similar to this from the command line would be great:
rustc /path/to/main.rs --dependency serde_json, my_package ...
You can specify a dependency with with extern flag, and you can specify the location of transitive dependencies, with -L dependency. You will have to compile each dependency, and all of it's dependencies manually:
// compile all of serde's dependencies
// compile all of hyper's dependencies
// compile serde
// compile hyper
rustc script.rs --crate-type bin -L dependency=~/tmp/deps --extern serde_json=~/tmp/deps/serde_json.rlib --extern hyper=~/tmp/deps/hyper.rlib
As you can tell, this would get very difficult, even with two direct dependencies. Instead, you can use cargo-script, which handles all of this for you:
cargo install cargo-script
cargo script -D hyper -D serde_json script.rs

Could not able to release a file. getting error: could not compile 'libc'

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.

How to troubleshoot why cargo/rustc links in rust standard library symbols even when no_std is used?

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.

How can you compile a Rust library to target asm.js?

I've got a Rust library with the following usual structure:
Cargo.toml
src
|--lib.rs
.cargo
|--config (specifies target=asmjs-unknown-emscripten)
target
|......
When I do cargo build, I get a new directory under target called asmjs-unknown-emscripten, but the .js files that I'd expect are not there.
As this user notes, you've got to do something special to export functions to asm.js besides marking them public:
Basically you have this boilerplate right now:
#[link_args = "-s EXPORTED_FUNCTIONS=['_hello_world']"]
extern {}
fn main() {}
#[no_mangle]
pub extern fn hello_world(n: c_int) -> c_int {
n + 1
}
Then you can use this in your javascript to access and call the function:
var hello_world = cwrap('hello_world', 'number', ['number']);
console.log(hello_world(41));
However, Rust complains about the #[link_args...] directive as deprecated. Is there any documentation out there that can explain how this works?
Very interesting question! I was running into similar dependency issues with fable.
I have checked Compiling Rust to your Browser - Call from JavaScript, Advanced Linking - Link args and How to pass cargo linker args however was not able to use cargo in the same way as rustc --target asmjs-unknown-emscripten call-into-lib.rs.
The closer I was able to get was to run both cargo and rustc like
cd lib1
cargo build --target asmjs-unknown-emscripten
rustc --target=asmjs-unknown-emscripten src\lib.rs
cd ..
cd lib2
cargo build --target asmjs-unknown-emscripten
rustc --target=asmjs-unknown-emscripten src\lib.rs --extern lib1=..\lib1\target\asmjs-unknown-emscripten\debug\liblib1.rlib
cd ..
cd lib3
cargo build --target asmjs-unknown-emscripten
rem rustc --target=asmjs-unknown-emscripten src\lib.rs --extern webplatform=..\lib3\target\asmjs-unknown-emscripten\debug\deps\libwebplatform-80d107ece17b262d.rlib
rem the line above fails with "error[E0460]: found possibly newer version of crate `libc` which `webplatform` depends on"
cd ..
cd app
cargo build --target asmjs-unknown-emscripten
cd ..
see the so-41492672-rust-js-structure. It allows to have several libraries that compile together to the JavaScript in the final application.
I still think some manual linking would help. Would be interested to know.
P.S. to see what rustc uses to link, you can pass -Z print-link-args to it.

Resources