My current understanding is that stable releases are subsets of nightly (essentially with every feature flag turned off), given this is there a way to get the corresponding nightly release for a stable release?
Specifically would rustc 1.62.0-nightly (without any feature flags) have identical behavior to rustc 1.62.0?
Stable releases do not use the same code as nightly ones. Nightly releases are built off of the master branch, whereas stable releases have their own branch off of nightly with fixes backported. See also the page for how Rust's Git branching works.
The version subcommand or --version argument to most rust tools (cargo, rustc, etc) should print the git hash along with the version info, which will tell you exactly what version of the source it was built against. Additionally, stable releases are tagged in the Git repo.
Related
I am using cargo on a Chromebook Lenovo Duet 5. I have this error just as I try to code something a little more complex. I was trying to import an image package and got this error:
this version of Cargo is older than the `2021` edition, and only supports `2015` and `2018` editions.
I suspect that maybe that image package is only built for x86_64 and I just happen to be learning Rust on ARM. I tried to build cargo from source using the binary cargo I have, but that also has the same error.
Your problem is not a platform difference; you simply have an old version. The 2021 language edition was added with Rust release version 1.56.0, in October 2021. You need to install a Rust version that is at least that new.
The recommended way to install and maintain a Rust toolchain is with Rustup. I can personally confirm that it will work on ARM Chromebook Linux.
I've been trying to use gitVersion to increment a project to version 1.0.0 after some time of incrementing minor and patch versions.
When using +semver: major the minor version is incremented. for example, version 0.1.1 got incremented to 0.2.0.
In the official documentation it says the following:
One thing to be aware of: If the current version is an alpha-version
(i.e. 0.x.y.), attempting to bump the major version will merely bump
the minor (eg from 0.2.0 to 0.3.0 instead of 1.0.0). Once the current
version is greater than 1.0.0, bumping the major version works as
expected.
I am currently not using a custom configuration file and I was wondering if it is possible to increment the version to 1.0.0 without adding one.
As documented
If you are using next-version and are experiencing weird versioning behaviour, please remove it, create a git tag with an appropriate version number on an appropriate historical commit and see if that resolves any versioning issues you may have
You can set a new version tag like
git tag -a v1.0.0 -m "v1.0.0" on the repository,
gitversion will calculate semVer from the V1.0.0
git tag -a v1.0.0 -m "v1.0.0"
I see this error in the Terminal while building a Rust application (which happens to be about NEAR Protocol, if you're curious):
error[E0463]: can't find crate for core
note: the "wasm32-unknown-unknown" target may not be installed
How can I fix it so that Rust will actually build my NEAR app?
To solve this error, run:
rustup target add wasm32-unknown-unknown
in the terminal, and that should correct the issue.
Note: I'm simply posting here as an answer what the original question asker Dorian Crutcher already wrote within their question. But that suggestion did work for me too.
I had the same problem, its reason is in an out-of-date version of Rust, the solution was to update the Rust to the latest version.
I got a similar error while trying to install universal builds of py38-cryptography via Macports on Mac OS 12.1 with an M1 Max chip.:
:info:build error[E0463]: can't find crate for `core`
:info:build |
:info:build = note: the `x86_64-apple-darwin` target may not be installed
Rebuilding Macports' installed version of rust as universal works:
sudo port install rust +universal
For future readers (mostly myself) who run into this issue, there's another important factor that could be causing this error or similar errors which is extremely hard to realize: conflicting versions of Rust and/or Cargo. This means it persists even after running rustup target add wasm32-unknown-unknown.
In my case, I had rust installed from brew and rustup at the same time, which was causing a bunch of confusion and clashes. You should make sure you have Rust installed exclusively from rustup. Double check every package manager you have on your system, because rust may have been installed as a dependency of another package, such as through cargo-nextest in my case. Such packages should be uninstalled and managed instead through cargo itself, and thus kept under the purview of rustup.
I also ran into this problem for a different reason. I had explicitly specified the version of nightly compiler to rustup as version nightly-YYYY-MM-DD, but inside a toolchain file, I only specified nightly which I suspect refers to the latest nightly for which core, among many other things, was indeed not installed.
May be somebody will help, ubuntu 20.04, just randomly found solution of next error:
error[E0463]: can't find crate for core
Run in terminal, rustup target add wasm32-unknown-unknown
rustup help toolchain lists the following sub-commands
SUBCOMMANDS:
list List installed toolchains
install Install or update a given toolchain
uninstall Uninstall a toolchain
link Create a custom toolchain by symlinking to a directory
help Prints this message or the help of the given subcommand(s)
I have the following toolchains installed
stable-x86_64-unknown-linux-gnu (default)
nightly-2019-09-05-x86_64-unknown-linux-gnu
nightly-x86_64-unknown-linux-gnu
master
I was trying to solve an issue for rust-clippy so I had to install the master toolchain. Even though stable is set as my default toolchain, my current toolchain is master and I would like to switch back to stable. How do I do it without uninstalling the master toolchain?
Is there no switch subcommand?
Of course the rustup default stable command works well, but the easiest way is to keep a rust-toolchain file inside your project root folder. Similar to how you'd keep a .nvm file for a Node.js project.
Please note that if you use rust-toolchain.toml instead of just rust-toolchain you will need to add needed sections similar to JSON ref and hence I prefer just the simple rust-toolchain file which doesn't need any sections similar to Node.js's .nvm file.
rust-toolchain
nightly
or
stable
Use rustup default <toolchain> to change the default toolchain. You can use the full name (e.g. rustup default stable-x86_64-unknown-linux-gnu) or a short alias (e.g. rustup default stable).
rustup also has methods to override the default in a more scoped manner. See Overrides in the rustup book.
To toggle between nightly and stable configurations in your repo use:
rustup override set nightly
or:
rustup override set stable
rustup default stable should work. This will set stable as the default toolchain globally.
To set stable as the default toolchain for just one directory/ project, use rustup override set stable command instead. To unset it, use rustup override unset.
I was trying to build a Yocto Image for intel processor.
I downloaded the latest source code of poky and then clone the meta-intel branch and added it to bblayers.conf file.
git clone git://git.yoctoproject.org/meta-intel
MACHINE = "intel-core2-32"
I started build with the following command
bitbake core-image-sato
And got the following error:
configure: error: Package requirements (libva >= 1.1.0) were not met:
|
| Requested 'libva >= 1.1.0' but version of libva is 0.40.0
|
| Consider adjusting the PKG_CONFIG_PATH environment variable if you
| installed software in a non-standard prefix.
|
I have the following recipe in this folder meta/recipes-graphics/libva/libva_1.8.3.bb
It means the version should be 1.8.3 instead of 0.4.0
The version of libva that configure is looking for (in some recipe you didn't name) is the API version. This is not necessarily the same as the package version. libva is one of the examples where package/recipe version and API version are not too related.
libva 1.x provides API version 0.y . Yes, it's weird.
Your real problem is here:
I downloaded the latest source code of poky and then clone the
meta-intel branch
meta-intel is not a branch, it's a layer and git repo. If you did not specifically change the branch of that git repo, you are using master. This is typically not compatible with release versions of poky.
If you want to keep using the poky release you've downloaded, you must checkout the matching release branch/tag in meta-intel.
This is not required to fix your issue but I would suggest using git to get all of your layers, poky included. That way it's easy to pick the branches you want (and the method to do that is the same for all layers) and also easier to upgrade when e.g. there's a bug fix release to poky...