After compiling my program 'zagir', the release folder has the size of more than 200MiB, which is ridiculous for the program I have written. So, I tried to check whether only the 'zagir' executable runs in isolation and it did.
But the confusion is that, release folder also includes libzagir.rlib file along with .d files and a bunch of other folders.
What exactly are they?
Are they really required?
Am I going to get error during execution when those files are ignored?
What are the files I should bundle for a complete executable?
Cargo.toml
[package]
authors = ["Sharad Chand"]
name = "zagir"
version = "0.1.0"
[dependencies]
bcrypt = "0.1.3"
dotenv = "0.10.1"
image = "0.17.0"
log = "0.3.8"
r2d2 = "0.7.3"
r2d2-diesel = "0.16.0"
rand = "0.3.16"
rocket = "0.3.2"
rocket_codegen = "0.3.2"
serde = "1.0.11"
serde_derive = "1.0.11"
serde_json = "1.0.2"
validator = "0.6.0"
validator_derive = "0.6.0"
[dependencies.bigdecimal]
features = ["serde"]
version = "0.0.10"
[dependencies.chrono]
features = ["serde"]
version = "0.4.0"
[dependencies.diesel]
features = [
"mysql",
"chrono",
"unstable",
"numeric",
"huge-tables",
]
version = "0.16.0"
[dependencies.diesel_codegen]
features = ["mysql"]
version = "0.16.0"
[dependencies.rocket_contrib]
features = ["handlebars_templates"]
version = "0.3.2"
[dependencies.uuid]
features = ["v4"]
version = "0.4"
Which files from the target directory are actually required by the executable
None of them, other than the executable itself. By default, Rust produces statically-linked binaries.
The other files are merely build artifacts maintained by Cargo in order to make rebuilding your code more efficient. They include things like your dependencies.
A non-exhaustive sampling of some of the files you might find:
*.d — Makefile-compatible dependency lists
*.rlib — Rust library files. Contain the compiled code of a dependency
build — Directories for build scripts to use as scratch space
deps — Your compiled dependencies
examples — Binaries from the examples directory
incremental — A directory for the incremental compilation cache
*-{hash} — Binaries from cargo test
executables — Your target binaries
Some of this is documented in the Cargo source code.
Related
I would like to program a bare attiny85 with rust. No existing development board, just my own layout. I figured that attiny-hal would be what I need, but I'm stuck at this error:
$ cargo check
Checking attiny-hal v0.1.0 (https://github.com/rahix/avr-hal?rev=4c9c44c314eb061ee20556ef10d45dea36e75ee4#4c9c44c3)
error: This crate requires you to specify your target chip as a feature.
Please select one of the following
* attiny85
* attiny88
* attiny167
* attiny2313
I tried these (and many other) settings in Crate.toml without success:
[package]
name = "avr01"
version = "0.1.0"
edition = "2021"
[features]
attiny85 = []
[dependencies.arduino-hal]
git = "https://github.com/rahix/avr-hal"
rev = "4c9c44c314eb061ee20556ef10d45dea36e75ee4"
features = ["attiny-hal"]
How do I select the target chip?
In your dependencies you have listed arduino-hal but you say you're programming a bare attiny85. You should include the attiny-hal crate directly and specify one of those features on the crate for example using this cargo command for an attiny85:
cargo add --git "https://github.com/rahix/avr-hal" attiny-hal -F attiny85
Which for some reason (I believe it's a bug) currently thinks attiny85 isn't a feature of attiny-hal but you can just specify it
in your Cargo.toml. The key for attiny-hal should include the required feature:
[dependencies.attiny-hal]
git = "https://github.com/rahix/avr-hal"
version = "*"
features = ["attiny85"]
Building the following rust file is producing a binary of 720KB.
I would expect a virtually empty build, what am I missing here? Is the full core libary getting included somehow?
Here's the code
#![no_std]
#[panic_handler]
fn handle_panic(_: &core::panic::PanicInfo) -> ! {
unreachable!()
}
And the cargo.toml
[package]
name = "wasm_test"
version = "0.0.0"
edition = "2021"
[lib]
crate-type = ["cdylib"]
[profile.release]
opt-level = 's'
lto = true
And the command I'm using to build:
cargo build --target wasm32-unknown-unknown
Ok turns out I had two problems:
I was building this as a crate in a workspace, and that apparently ignores crate specific profiles
When i copied the crate out to mess around with it and isolate the problem, i was forgetting to add the --release flag, thanks #isaactfa.
In other cases i have received this warning.
warning: profiles for the non root package will be ignored, specify profiles at the workspace root:
for some reason I wasn't getting it when doing the workspace builds.
I've added the crate to the workspace exclude list and am building it seperately, and its compiling to a far more appropriate 411 bytes, down from 727151 bytes.
I have recently been working on a game engine in rust and for rendering I have been planning on using the wgpu crate. When I add this to my dependancies wgpu-hal fails to build with 448 errors. my cargo.toml for this crate looks like this
[package]
name = "ferrogame"
version = "0.1.0"
edition = "2021"
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
[dependencies]
log = "0.4.17"
fern = {version = "0.6.1", features = ["colored"]}
chrono = "0.4.22"
winit = "0.27.2"
rapier3d = "0.15.0"
rapier2d = "0.15.0"
wgpu = "0.14.0"
[lib]
crate-type = ["rlib"]
This is especially strange because I made a new crate with only wgpu as a dependency and it compiled fine that time. I have tried updating rust and running cargo update but nothing has worked. How can I fix this?
This issue is due to a version conflict.
Rapier uses bevy at version 0.8, and bevy version 0.8 depends on wgpu at version 0.13
What could be a possible reason for cargo build immediately after cargo check recompiling many (but not all) dependencies?
Cargo.toml
[package]
name = "greeter"
version = "0.1.0"
authors = ["Near Inc <hello#near.org>"]
edition = "2018"
[lib]
crate-type = ["cdylib", "rlib"]
[dependencies]
near-sdk = "3.1.0"
[profile.release]
codegen-units = 1
# Tell `rustc` to optimize for small code size.
opt-level = "z"
lto = true
debug = false
panic = "abort"
# Opt into extra safety checks on arithmetic operations https://stackoverflow.com/a/64136471/249801
overflow-checks = true
[workspace]
members = []
cargo check is not a build. It simply checks that your code would compile, but doesn't necessarily build anything. See here for more information.
So cargo build will need to actually build some crates, that where not built during cargo check. Other crates may need to be fully compiled to check (for example crates used in a build.rs script or by procedural macros), and where therefore already compiled when you ran cargo build.
When I run the build command
cargo build-bpf --manifest-path=Cargo.toml --bpf-out-dir=dist/program
error: failed to download solana-frozen-abi v1.7.9
Caused by:
unable to get packages from source
Caused by:
failed to parse manifest at /home/USER/.cargo/registry/src/github.com-1ecc6299db9ec823/solana-frozen-abi-1.7.9/Cargo.toml
Caused by:
feature resolver is required
There have been people with similar issues but the cause was old rustc version. Mine looks ok
rustc --version
rustc 1.55.0-nightly (7c3872e6b 2021-06-24)
cargo --version
cargo 1.55.0-nightly (9233aa06c 2021-06-22)
My Cargo.toml file looks like
[package]
name = "test"
version = "0.0.1"
edition = "2018"
exclude = ["tests/**"]
[features]
no-entrypoint = []
test-bpf = []
[dependencies]
borsh = "0.8.2"
num-derive = "0.3"
num-traits = "0.2"
solana-program = "1.6.10"
spl-token = { version="3.1.1", features = [ "no-entrypoint" ] }
thiserror = "1.0"
[dev-dependencies]
solana-program-test = "1.6.10"
solana-sdk = "1.6.10"
[lib]
crate-type = ["cdylib", "lib"]
I have downloaded the metaplex rust code (exact same dependencies) and the build bpf command compiles successfully.
I have also tried running cargo clean which doesnt change anything.
I fixed it by updating to the latest version (1.7.9) of Solana (which is not the release version):
sh -c "$(curl -sSfL https://release.solana.com/v1.7.9/install)"
The same inputs from Cargo.toml do not mean the the Rust build will be repeatable on other machines — Cargo.lock contains the exact versions used. Additionally, cargo clean doesn't remove Cargo.lock
https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lock.html