Why my project still saying "i am unoptimized"?
I am doing a normal build and terminal says this build is unoptimized
And i am doing a release build and it says it optimized
but when i enter cargo check command it says unoptimized
Because unoptimized + debuginfo is the default for all commands in cargo.
To run any command in release, please add the --release flag as you already did with cargo build:
cargo check --release
For optimized builds in debug mode add these lines to your Cargo.toml:
[profile.dev]
opt-level = 3
You can find more information about customizing build profiles here: https://doc.rust-lang.org/book/ch14-01-release-profiles.html
Related
I'm specifying the -Cpanic=abort and -Zbuild-std=panic_abort when compiling. Why does the linker still say it needs libunwind to compile a program?
I'm experimenting with various ways to cross-compile Rust programs as small as possible (using the min-sized-rust repo as a reference). Right now I'm trying to compile the powerpc64-unknown-linux-musl target and I'm stuck on trying to remove a dependency on libunwind.
Here's my setup:
# 1. Install the Rust std source code
rustup component add rust-src --toolchain nightly
# 2. Setup a simple rust repo
cargo init testing
cd testing
# 3. Download a musl toolchain
wget https://musl.cc/powerpc64-linux-musl-cross.tgz
tar xzf powerpc64-linux-musl-cross.tgz
# 4. Try to compile the project (options on the command line instead of in files for
# maximum obviousness).
# RUSTFLAGS:
# -Cpanic=abort - abort immediately on panic
# -Clink-self-contained=no - don't use rustc's builtin libraries and objects (this
# is needed because powerpc64-unknown-linux-musl is a tier 3 target)
# -Clink-arg=--sysroot and -Clink-arg=/path/to/sysroot - pass the option to the linker
# to specify the sysroot of cross-compilation toolchain
# Cargo options:
# --config target.<triple>.linker - specify the linker to use
# -Zbuild-std=std,panic_abort - build the standard library from source. Specify
# panic_abort to make the abort on panic work
RUSTFLAGS="-Cpanic=abort -Clink-self-contained=no -Clink-arg=--sysroot -Clink-arg=powerpc64-linux-musl-cross/powerpc64-linux-musl/" \
cargo +nightly build \
--config "target.powerpc64-unknown-linux-musl.linker=\"powerpc64-linux-musl-cross/bin/powerpc64-linux-musl-gcc\"" \
--target powerpc64-unknown-linux-musl -Zbuild-std=panic_abort,std --release
This fails with the following error:
error: linking with `/home/user/Projects/testing/powerpc64-linux-musl-cross/bin/powerpc64-linux-musl-gcc` failed: exit status: 1
<output snipped>
= note: /home/user/Projects/testing/powerpc64-linux-musl-cross/bin/../lib/gcc/powerpc64-linux-musl/11.2.1/../../../../powerpc64-linux-musl/bin/ld: cannot find -lunwind
From min-size-rust repository:
"Even if panic = "abort" is specified in Cargo.toml, rustc will still include panic strings and formatting code in final binary by default. An unstable panic_immediate_abort feature has been merged into the nightly rustc compiler to address this.
To use this, repeat the instructions above to use build-std, but also pass the following -Z build-std-features=panic_immediate_abort option."
Still, you will get "cannot find -lunwind", because the linker still uses libunwind, even though it's truly unneeded,why! I do not know, maybe it's a bug.(Maybe someone with fair knowledge about linkers can easily solve that.I tried a naive solution which is "cargo .... --verbose", copy , remove "libunwind" then relinking which failed)
I verified that is indeed the missing piece by build from source(--target=x86_64-unknown-linux-musl) AND using an old simple trick which is "touch libunwind.a" in the "self-contained" directory inside a target lib folder.(because the linker would still use it even though it's now truly unneeded, then I gave him a dummy libunwind.a)
In your case, I really tried to build it to your target until I got a headache, but couldn't and stopped, but here is possible solutions:
Giving that you're using "-Z build-std-features=panic_immediate_abort"
-If you can custom the linking process, then solve it (until what seems to be a bug is solved)
-Create a dummy(empty) libunwind.a where it should be in your toolchain
Windows 10
rustup 1.23.1 (3df2264a9 2020-11-30)
default rustc 1.50.0 (cb75ad5db 2021-02-10)
project rustc 1.52.0-nightly (4a8b6f708 2021-03-11)
rocket = "0.4.4"
I'm trying to build a rust project with rocket but I always get this error when compiling, even after successfully overwriting the project's toolchain:
D:\GitHub\Learning-Rust\poke_api> rustup override set nightly
info: using existing install for 'nightly-x86_64-pc-windows-msvc'
info: override toolchain for 'D:\GitHub\Learning-Rust\poke_api' set to 'nightly-x86_64-pc-windows-msvc'
nightly-x86_64-pc-windows-msvc unchanged - rustc 1.52.0-nightly (4a8b6f708 2021-03-11)
PS D:\GitHub\Learning-Rust\poke_api> cargo build
Compiling winapi v0.3.9
Compiling serde_derive v1.0.124
Compiling rocket v0.4.7
Compiling pear_codegen v0.1.4
Compiling rocket_codegen v0.4.7
Compiling proc-macro2 v1.0.24
Compiling pq-sys v0.4.6
Compiling aho-corasick v0.6.10
Compiling serde_json v1.0.64
error: failed to run custom build command for `pear_codegen v0.1.4`
Caused by:
process didn't exit successfully: `D:\GitHub\Learning-Rust\poke_api\target\debug\build\pear_codegen-e182711746033ac9\build-script-build` (exit code: 101)
--- stderr
Error: Pear requires a 'dev' or 'nightly' version of rustc.
Installed version: 1.48.0 (2020-11-16)
Minimum required: 1.31.0-nightly (2018-10-05)
thread 'main' panicked at 'Aborting compilation due to incompatible compiler.', C:\Users\gabre\.cargo\registry\src\github.com-1ecc6299db9ec823\pear_codegen-0.1.4\build.rs:24:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
error: build failed
I had a similar issue while using rocket. Same error message too, Error: Pear requires a 'dev' or 'nightly' version of rustc.
If you get to the get-started page on rocket framework website. It says, "Rocket makes abundant use of Rust's syntax extensions and other advanced, unstable features. Because of this, we'll need to use a nightly version of Rust."
My issue was I was not using a nightly version of rust. Running this on my terminal in my project directory did it for me.
rustup override set nightly
If you check the cargo version for that directory after,
cargo version
you will confirm it has switched to nightly version
Failed compilation even with nightly
It looks like you have some outdated dependencies (pear-codegen probably being the one that causes trouble), updating these may resolve the compilation issues.
General notes on how to override the toolchain
Using rustups override works fine, but it is bound to your local rustup configuration and not specified inside the project.
In order to achieve this, thereby making the project more portable and allowing others to always use the correct toolchain, I would recommend the toolchain file. It can look something like this (example taken from linked page) and will accurately specify the required toolchain only for the containing project.
# rust-toolchain.toml
[toolchain]
channel = "nightly-2020-07-10"
components = [ "rustfmt", "rustc-dev" ]
targets = [ "wasm32-unknown-unknown", "thumbv2-none-eabi" ]
profile = "minimal"
For your purposes a simple configuration like this will most likely be all you need, although adding the components you want to use would be beneficial.
[toolchain]
channel = "nightly"
My issue was with rust-analyser that wouldn't start because multiple rocket dependencies needed nightly or dev version of rustc.
These steps fixed my issue:
Switch to nightly for my rocket project by running rustup override set nightly inside the app folder.
Remove all target folders in my project. (I also had one in root)
Manually remove the faulty cached packages from cargo cache. cd ~/.cargo/registry/cache/github.com-xxxxxxxxxxxx && rm -r pear_codegen-0.1.5/
I have a basic rust/cargo project with a single main file and some basic dependencies. The cargo build command works fine when the target is not specified (I am using windows so it builds to windows), but when I try to cross compile the program to linux using cargo build --target=x86_64-unknown-linux-gnu or cargo build --target=x86_64-unknown-linux-musl, the process fails with the following error: linker 'cc' not found.
Does anyone have an idea how to get around this? Is there a specific linker I need to install?
Thanks.
I've just figured it out.
It turns out you need to tell cargo to use the LLVM linker instead. You do this by creating a new directory called .cargo in your base directory, and then a new file called config.toml in this directory. Here you can add the lines:
[target.x86_64-unknown-linux-musl]
rustflags = ["-C", "linker-flavor=ld.lld"]
Then building with the command cargo build --target=x86_64-unknown-linux-musl should work!
The output of rustup target list --toolchain nightly does not contain x86_64-apple-ios-macabi, even though it is in src/librustc_target on the Rust master branch.
How do I build for Mac Catalyst / x86_64-apple-ios-macabi?
The x86_64-apple-ios-macabi target is available on the nightly (5c5b8afd8 2019-11-16) compiler. Just because a target is available does not mean that the standard library and friends are compiled or available to rustup:
% rustc +nightly --print target-list | grep macabi
x86_64-apple-ios-macabi
Rust has a tier system (which is the subject of a proposed RFC). This target is so new it's not even listed on the tier list, but it's undoubtedly going to be tier 3. Tier 2.5 says (emphasis mine):
Tier 2.5 platforms can be thought of as "guaranteed to build", but without builds available through rustup
In the meantime, you will need to build your own libcore / libstd from source. I don't have the time nor ability to actually test that the compilation works, but something like these choices are the general starting path:
build-std
The unstable -Z build-std flag can be used to build the standard library:
% cargo +nightly build -Z build-std --target x86_64-apple-ios-macabi
Xargo
Building the standard library can be done using the xargo tool.
% rustup override set nightly
info: using existing install for 'nightly-x86_64-apple-darwin'
info: override toolchain for '/private/tmp/example' set to 'nightly-x86_64-apple-darwin'
nightly-x86_64-apple-darwin unchanged - rustc 1.41.0-nightly (5c5b8afd8 2019-11-16)
% cat > Xargo.toml
[target.x86_64-apple-ios-macabi.dependencies.std]
# features = ["jemalloc"] # Whatever is appropriate
% xargo build --target x86_64-apple-ios-macabi
# Iterate until libcore and libstd compile and work for your platform
#shepmaster 's answer is correct. In detail, you have to:
Install Xargo:
cargo install xargo
cd in your project
use the nighly build:
rustup override set nightly
create the Xargo.toml file with content:
[target.x86_64-apple-ios-macabi.dependencies.std]
In your projects Cargo.toml, make sure the [profile.release] section contains panic = "abort". If it does not, add it.
When building the project, use xargoinstead of cargo.
Shepmaster's answer is a little outdated. Cargo now supports the -Zbuild-std command. Using it, you can target any of the targets that rustc itself supports even if they aren't listed on rustup +nightly target list. Simply:
rustc +nightly --print target-list
and
cargo +nightly build -Z build-std --target x86_64-apple-ios-macabi
should be enough now. You don't need xargo to build the standard lib anymore.
If you have an old installation of rust, you might need to remove old nightly (or at least for me it fails to update nightly):
rustup toolchain remove nightly
rustup update
rustup toolchain install nightly
The program I'm writing runs much faster when the -C target-cpu=native flag is passed to rustc. I want to give users a simple, platform-independent way to enable this when compiling, so I added a Cargo feature cpu_native = [] in Cargo.toml and created this Cargo config in my project:
[target.'cfg(cpu_native)']
rustflags = ["-C", "target-cpu=native"]
However, this has no effect on my program, and passing --features cpu_native to Cargo does not even trigger a recompile. Changing to the following Cargo config does force re-compilation with faster instructions:
[build]
rustflags = ["-C", "target-cpu=native"]
However, this will compile with target-cpu=native with the default Cargo features, which was not what I wanted. From the Cargo book, what I want seems to be possible, but I don't see what I'm doing wrong.
I don't think this is supported (yet?). I enhanced Cargo to print out what config flags are checked against when resolving:
[
Name("debug_assertions"),
Name("proc_macro"),
KeyPair("target_arch", "x86_64"),
KeyPair("target_endian", "little"),
KeyPair("target_env", ""),
KeyPair("target_family", "unix"),
KeyPair("target_os", "macos"),
KeyPair("target_pointer_width", "64"),
Name("unix"),
]
[target.'cfg(cpu_native)']
This is the incorrect syntax for a Cargo feature; it would normally be cfg(feature = "cpu_native").