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).
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.
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.
I am trying to compile my Rust project with dynamic linking to reduce the size and provide .so (or .dll on Windows) files with the application just like Qt does for Android. I read Why are Rust executables so huge? and compiled with
cargo rustc -- -C prefer-dynamic
When I run my program, I get this error:
% target/debug/t_pro
target/debug/t_pro: error while loading shared libraries: libstd-a021829e87e39dcf.so: cannot open shared object file: No such file or directory
I got an answer on Reddit.
rustc --print=sysroot
In my case, the .so files are in /home/username/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib and .rlib are in /home/username/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib.
The libraries are installed wherever you chose to install Rust. I use rustup on macOS, so they are installed in ~/.rustup/toolchains/*whatever*/lib/ for me.
Use your operating system's tools to search for files of a specific name.
See also:
How to set the environmental variable LD_LIBRARY_PATH in linux
I just installed Rust with rustup on MacOS and noticed that there are two rustc and two cargo binaries:
~/.cargo/bin/rustc (cargo)
~/.rustup/toolchains/stable-x86_64-apple-darwin/bin/rustc (cargo)
Their versions are exactly the same, but diff shows there exists some difference. So why are there two different rustc (cargo) binaries and which one should I use?
The reason there are two files named rustc is because rustup is a toolchain multiplexer. It lets you install many versions of Rust and easily switch between them.
The binary installed at ~/.cargo/bin/rustc proxies to the current toolchain that you have selected. Each installed compiler is kept under the toolchains directory.
Although the compiler in the toolchains directory appears to be a smaller file, that's only because it's dynamically linked instead of statically linked.
More information can be found on rustup's README.
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