I downloaded a Rust project and built it with cargo build. I have not configured Rust beforehand. Where can I find the output binaries?
They'll be under target/debug or target/release depending on which configuration you built - if the command was just cargo build, then target/debug.
Related
I'm trying to build the (https://github.com/betterclever/solend-anchor) package using anchor build, however I get the following error
error: package `uint v0.9.3` cannot be built because it requires rustc 1.56.1 or newer, while the currently active rustc version is 1.56.0-dev
I updated rustc and running the command rustup default nightlyshows:
info: using existing install for 'nightly-x86_64-apple-darwin'
info: default toolchain set to 'nightly-x86_64-apple-darwin'
nightly-x86_64-apple-darwin unchanged - rustc 1.61.0-nightly
So it shows me that the installed and active rustc version is 1.61, however anchor build is not finding that for some reason. I also tried running cargo build-bpf but the same thing kept happening. cargo buildseemed to work fine.
I'm wondering what is causing the problem when running anchor build and cargo build-bpf?
anchor build and cargo build-bpf use a different compiler than the normal rustc compiler included in the system, so it's normal that they report a different version. The BPF compiler comes with the Solana tool suite.
If you already have the Solana tools installed on your computer, you can simply run:
solana-install init 1.9.13
And if you don't, you can run:
sh -c "$(curl -sSfL https://release.solana.com/v1.9.13/install)"
That will give you all of the newest tools, including the BPF compiler.
I have Solana latest version, I faced the same error while compiling one of the downloaded program.
Command
solana-install update
Worked for me.
In general, I compile everything in my workspace with: cargo build from the workspace directory, or with cargo build --workspace
However, if I then compile a specific package with cargo build -p package or by running cargo build from that package's directory, it will recompile it, when actually it should be completely cached, right?
It seems that the things being rerun are mostly related to macros... recompiling syn, serde_derive, etc...
Is it somehow expected that these macro crates need to be recompiled because they might give different results? I feel like that really shouldn't be the case if we want reproducible builds!
What can I do to prevent cargo from recompiling like this?
(this is with cargo 1.51.0 on a raspberry pi 4 running Raspbian 10)
I'm cross-compiling a Rust bare metal application for AArch64 target and I need to run unit tests on x86_64 target (my PC).
I created the file .cargo/config:
[build]
target = "aarch64-unknown-none"
I'd like to build for AArch64 but to run the tests for x86_64. If I change the build to x86_64-unknown-linux-gnu then the tests compile and execute. Is there a section where I could specify this? I have to swap these manually now.
I checked cargo guide but found no reference about test configuration.
You can achieve similar functionality by creating an alias in your .cargo/config file
[alias]
test_pc = "test --target=x86_64-unknown-linux-gnu"
then, you just just call
cargo test_pc
You cannot.
According to issue#6874, cargo doesn't have the feature to specify different target for cargo test.
FYI: you might have another solution for this issue if you use nightly, though I haven't made it work. The following links are about custom test framework, the issue opener says 'the solution'.
https://github.com/rust-lang/rust/pull/53410
https://blog.jrenner.net/rust/testing/2018/08/06/custom-test-framework-prop.html
I've used
cargo install --git https://github.com/steveklabnik/rustbook.git
to install rustbook successfully, but when I run rustbook I get an error:
rustbook: error while loading shared libraries: librustdoc-c0dcaea09a16c7ec.so: cannot open shared object file: No such file or directory
But I can find out this .so file.
./.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/librustdoc-c0dcaea09a16c7ec.so
./.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustdoc-c0dcaea09a16c7ec.so
How can I let rustbook know the path to librustdoc-c0dcaea09a16c7ec.so?
rustc 1.16.0-nightly (4ecc85beb 2016-12-28)
rustdoc 1.16.0-nightly (4ecc85beb 2016-12-28)
rustup show:
Default host: x86_64-unknown-linux-gnu
nightly-x86_64-unknown-linux-gnu (default)
rustc 1.16.0-nightly (4ecc85beb 2016-12-28)
This appears to be a known issue with rustup (#350, #765), specifically around cargo-installed binaries that were compiled against the nightly toolchain. If your application requires nightly to even compile, there's not much you can do other than rustup run nightly myprogram. This will start the program with the appropriate environment.
If the application doesn't require nightly Rust, then install it using the stable toolchain.
List the directory containing your shared library into /etc/ld.so.conf, or make a symlink from a path already listed there, or from /usr/lib (/usr/local/lib would be preferable, but maybe you have to add it to the list in ld.so.conf, so this would be again case 1).
Using Creating a basic webservice in Rust and Taking Rust everywhere with rustup as documentation, I have managed to successfully compile a 64 bit static binary with Rust:
rustup target add x86_64-unknown-linux-musl
cargo build --target=x86_64-unknown-linux-musl
But I can't seem to find out how to build a 32bit static binary.
I did find a i686-unknown-linux-musl target when running rustc --print target-list, only to find out it is not available when running rustup target list.
Am I missing something something or it is not possible yet?
The std binaries for i686-unknown-linux-musl is only available on Rust 1.10 or newer. You can create a static binary for i686 with the following commands:
$ rustup default stable # stable must at least 1.10
$ rustup target add i686-unknown-linux-musl
$ cargo build --target i686-unknown-linux-musl
The generated binaries can be found on target/i686-unknown-linux-musl/debug/ or target/i686-unknown-linux-musl/release/.
We can check that the generated binary is static linked with ldd:
$ ldd target/i686-unknown-linux-musl/debug/main
not a dynamic executable