rustc and cargo are supported in buildroot. But even the latest buildroot master uses rust version 1.33.0 stable I think.
How can I use the a nightly version of rust in buildroot?
Update: This patch http://lists.busybox.net/pipermail/buildroot/2016-April/159523.html introduces rust in buildroot. And this buildroot repo https://github.com/elebihan/buildroot/tree/feature/rust-1.33.0 has some latest rustc version.
This is for a QEMU ARM Vexpress, but I think it will get you where you are going:
Using Rust with Buildroot (full build)
You can skip up to the pushd command to the downloaded nightly rust source. Instead of doing all that, just use the location of the code you got when you run rustup install nightly (or however else you're installing the nightly snapshot`).
I hope that helps.
If the build commands don't need to be changed, you can just download the source to some directory and add RUST_OVERRIDE_SRCDIR=<path to rust source> in your local.mk. See the Buildroot manual.
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 our project we need to use an unstable cargo option --out-dir, but we still want to use stable rustc to build our rust code. Is this possible?
You should be able to configure the nightly cargo executable to use the stable rustc compiler by modifying the build.rustc key. You could delegate this to the stable compiler if rustup is installed by setting the value to be rustup run stable rustc.
You can use the __CARGO_TEST_CHANNEL_OVERRIDE_DO_NOT_USE_THIS environment variable to override the Cargo channel. As the name suggests, it's not really intended to be used. But you can! Keep in mind that with this approach you only get the unstable features included in the latest stable release (and important fixes for unstable features aren't going to get backported to the stable branch, because this shouldn't be used)
# Allow unstable options in Cargo, but use stable rustc
__CARGO_TEST_CHANNEL_OVERRIDE_DO_NOT_USE_THIS=nightly cargo build -Z unstable-options
Trying to compile: https://github.com/SergioBenitez/Rocket/tree/master/examples/hello
Cargo.toml
[dependencies]
rocket = "0.4.10"
Complains that I need rust nightly
$ cargo build
...
Error: Rocket (core) requires a more recent version of rustc.
Installed version: 1.54.0 (2021-05-17)
Minimum required: 1.54.0-nightly (2021-05-18)
I have done a local directory override
$ rustup override set nightly
I am running nightly 2021-05-17 but I need 2021-05-18
$ rustup show
...
active toolchain
----------------
nightly-x86_64-unknown-linux-gnu (directory override for '/<redacted>')
rustc 1.54.0-nightly (3e99439f4 2021-05-17)
I've tried all sorts of commands to get a more recent nightly
$ rustup update
$ rustup update nightly
$ rustup toolchain install nightly-2021-05-18
There is some weird stuff when I do rustup update nightly
$ rustup update nightly
info: syncing channel updates for 'nightly-x86_64-unknown-linux-gnu'
info: latest update on 2021-05-23, rust version 1.54.0-nightly (e4ca1662f 2021-05-22)
info: skipping nightly which is missing installed component 'rls'
info: syncing channel updates for 'nightly-2021-05-22-x86_64-unknown-linux-gnu'
info: latest update on 2021-05-22, rust version 1.54.0-nightly (5dc8789e3 2021-05-21)
info: skipping nightly which is missing installed component 'rls'
info: syncing channel updates for 'nightly-2021-05-21-x86_64-unknown-linux-gnu'
info: latest update on 2021-05-21, rust version 1.54.0-nightly (40d230204 2021-05-20)
info: skipping nightly which is missing installed component 'rls'
info: syncing channel updates for 'nightly-2021-05-20-x86_64-unknown-linux-gnu'
info: latest update on 2021-05-20, rust version 1.54.0-nightly (f94942d84 2021-05-19)
info: skipping nightly which is missing installed component 'rls'
info: syncing channel updates for 'nightly-2021-05-19-x86_64-unknown-linux-gnu'
info: latest update on 2021-05-19, rust version 1.54.0-nightly (4e3e6db01 2021-05-18)
info: skipping nightly which is missing installed component 'rls'
info: syncing channel updates for 'nightly-2021-05-18-x86_64-unknown-linux-gnu'
nightly-x86_64-unknown-linux-gnu unchanged - rustc 1.54.0-nightly (3e99439f4 2021-05-17)
Complains about skipping nightly which is missing installed component 'rls' and I have no idea how to resolve this
Any help would be appreciated
Sorry for the wall of text, see The solution to your problem below if you only want a quick fix. You might also look at the rustup book, it contains information about this type of problem.
You are trying to install a nightly version of Rust. In nightly versions, the availability of non-essential components of Rust, such as the Rust Language Server (or short rls) is not guaranteed – if they fail to build, the nightly is shipped without them. You can see here that rls indeed was not part of the last few nightlies. The last day a nightly was shipped with rls was 2021-05-18, which is a build from the day before, so 2021-05-17 (a bit irritating, but this seems to be accepted behavior).
Your rustup installation seems to be configured to include rls. Therefore, when you tell rustup to update your nightly toolchain, rustup selects the newest nightly containing rls. There are no such nightlies newer than your currently installed nightly-2021-05-17, therefore, rustup does not update the toolchain.
The solution to your problem
If you don't need rls (it's only necessary for auto-completion in IDEs and stuff like that), there are multiple solutions to your problem:
You can remove the rls component from your nightly toolchain: rustup component remove --toolchain nightly rls
The rustup book also has some more solutions:
If [a previously installed component] is missing, rustup will automatically search for an older release that contains the required components. There are several ways to change this behavior:
Use the --force flag to rustup toolchain install to force it to install the most recent version even if there is a missing component.
Use the --profile flag to rustup toolchain install to use a different profile that does not contain the missing component. For example, --profile=minimal should always work, as the minimal set is required to exist. See the Profiles chapter for more detail.
Install a specific date that contains the components you need. For example, rustup toolchain install nightly-2020-07-27. You can then use overrides to pin to that specific release.
If you do need rls, you are in a bit of a tight spot. You might want to use a override for your project, in effect using different Rust builds for building your code and for running rls. However, this will probably not work – rls may need to build your project dependencies for autocompletion, and Rocket will not allow that with older nightlies. I don't really have a solution for this case – you may need to stay on an older version of Rocket or stop using rls for now, until there is a newer Rust nightly shipping with rls again.
My machine have rust nightly-2020-03-24, I want to compile cross-compile crate core. But the command rustup component add rust-src install newest version of rust-src, which rustc-2020-03-24 can't build (due to new feature llvm-asm). How can I install old version of rust-src?
If not already installed, you can get a specific version of a component by specifying the toolchain when calling rustup (like +stable, +1.44, etc). In your case:
rustup +nightly-2020-03-24 component add rust-src
The source can then be found in ~/.rustup/toolchains/nightly-2020-03-24-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/.
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).