I would like to set up a toolchain override for one of my rust projects to use the GNU toolchain instead of the default MSVC one. But somehow the configuration in rust-toolchain.toml is ignored. (I am up to date it is not because of the extension.)
Here is how it goes:
λ rustup show
Default host: x86_64-pc-windows-msvc
rustup home: C:\Users\<username>\scoop\persist\rustup\.rustup
installed toolchains
--------------------
stable-x86_64-pc-windows-gnu
stable-x86_64-pc-windows-msvc (default)
installed targets for active toolchain
--------------------------------------
x86_64-pc-windows-gnu
x86_64-pc-windows-msvc
active toolchain
----------------
stable-x86_64-pc-windows-msvc (default)
rustc 1.57.0 (f1edd0429 2021-11-29)
As you can see I have the GNU toolchain installed.
So I created the following rust-toolchain.toml file:
λ cat rust-toolchain.toml
[toolchain]
channel = "stable"
targets = ["x86_64-pc-windows-gnu"]
Now when I run rustup show I get a result showing the tool is seeing the file, but it does not seem to be processing it correctly since it still wants to use msvc.
λ rustup show
Default host: x86_64-pc-windows-msvc
rustup home: C:\Users\<username>\scoop\persist\rustup\.rustup
installed toolchains
--------------------
stable-x86_64-pc-windows-gnu
stable-x86_64-pc-windows-msvc (default)
installed targets for active toolchain
--------------------------------------
x86_64-pc-windows-gnu
x86_64-pc-windows-msvc
active toolchain
----------------
stable-x86_64-pc-windows-msvc (overridden by 'C:\<project path>\rust-toolchain.toml')
rustc 1.57.0 (f1edd0429 2021-11-29)
My guess is that for some reason x86_64-pc-windows-gnu is considered a valid target for the stable-x86_64-pc-windows-msvc toolchain, but I do not understand why, how to prevent it, or how to write in the rust-toolchain.toml file that I want to to use the x86_64-pc-windows-gnu target of the stable-x86_64-pc-windows-gnu toolchain and not the one of the stable-x86_64-pc-windows-msvc toolchain.
How do you think I could solve this?
Note: using rustup default stable-gnu works as expected but I would like to be able to commit something in the repository so that other contributors (and their tools) know they need to use this specific toolchain.
Edit: rustup version just in case.
λ rustup -V
rustup 1.24.3 (ce5817a94 2021-05-31)
Related
It looks like it has updated to 1.64.0, which is what I want, but then when I check the version, the update did not happen.
root#c1:~# rustup update
info: syncing channel updates for 'stable-x86_64-unknown-linux-gnu'
info: checking for self-updates
stable-x86_64-unknown-linux-gnu unchanged - rustc 1.64.0 (a55dd71d5 2022-09-19)
info: cleaning up downloads & tmp directories
root#c1:~# rustc --version
rustc 1.58.0-nightly (072799443 2021-11-06)
that is because rustup updated a different rust installation than the one you checked its version using rustc --version.
you can see that rustup has updated a stable version of rust while rustc is nightly, as the 1st comment said. run which rustc and rustup show to locate both installations and then fix your paths accordingly
I am using rustup to update the rust version, is it possible to specify the source in the command line like this?
rustup update --source http://rustup.com
I already know how to config the mirror url in .cargo/config, I just want to switch the source in temporary in the command lne. Seems no way to do this from official document:
➜ .cargo rustup update --help
rustup-update
Update Rust toolchains and rustup
USAGE:
rustup update [FLAGS] [toolchain]...
FLAGS:
--force Force an update, even if some components are missing
--force-non-host Install toolchains that require an emulator. See https://github.com/rust-
lang/rustup/wiki/Non-host-toolchains
-h, --help Prints help information
--no-self-update Don't perform self update when running the `rustup update` command
ARGS:
<toolchain>... Toolchain name, such as 'stable', 'nightly', or '1.8.0'. For more information see `rustup help
toolchain`
DISCUSSION:
With no toolchain specified, the `update` command updates each of
the installed toolchains from the official release channels, then
updates rustup itself.
If given a toolchain argument then `update` updates that
toolchain, the same as `rustup toolchain install`.
I try to run
rustup update stable
and I get the following output.
info: syncing channel updates for 'stable-x86_64-unknown-linux-gnu'
info: latest update on 2020-05-07, rust version 1.43.1 (8d69840ab 2020-05-04)
error: some components unavailable for download for channel stable: 'rust-std' for target 'i386-apple-ios', 'rust-std' for target 'armv7s-apple-ios', 'rust-std' for target 'armv7-apple-ios'
If you require these components, please install and use the latest successful build version,
which you can find at <https://rust-lang.github.io/rustup-components-history>.
After determining the correct date, install it with a command such as:
rustup toolchain install nightly-2018-12-27
Then you can use the toolchain with commands such as:
cargo +nightly-2018-12-27 build
While I can install the latest stable toolchain using
rustup toolchain install stable-2020-05-07
That creates a separate toolchain.
rustup toolchain list
stable-2020-05-07-x86_64-unknown-linux-gnu (default)
stable-x86_64-unknown-linux-gnu
nightly-2020-05-07-x86_64-unknown-linux-gnu
I can use this new toolchain as the default (as I am now), but it's going to be a pain moving forward as I can't just use rustup update.
Running rustup toolchain install stable yields the same error.
How can I get the stable Rust toolchain to update via rustup update run?
The Rust team regrets to announce that Rust 1.41.0 (to be released on January 30th, 2020) will be the last release with the current level of support for 32-bit Apple targets. Starting from Rust 1.42.0, those targets will be demoted to Tier 3.
Reducing support for 32-bit Apple targets
You will need to remove those components using rustup component remove. I can't test the exact invocation, but something like:
rustup component remove --toolchain stable --target i386-apple-ios rust-std
rustup component remove --toolchain stable --target armv7s-apple-ios rust-std
rustup component remove --toolchain stable --target armv7-apple-ios rust-std
Once removed, you can update your compiler.
I am using rustc and cargo on my 64-bit Windows machine to compile a 32-bit application. This work fine when using the stable toolchain, but when I try to use the beta toolchain it fails.
The beta toolchain was successfully installed with rustup install beta. In the project folder there is a .cargo/config file containing the following lines:
[build]
target = "i686-pc-windows-msvc"
[target.i686-pc-windows-msvc]
rustflags = ["-Ctarget-feature=+crt-static"]
When running cargo +beta build the following error occurs:
error[E0463]: can't find crate for `core`
|
= note: the `i686-pc-windows-msvc` target may not be installed
I have tried running rustup target add i686-pc-windows-msvc to fix the issue but it didn't help; rustup target list even displays it as "installed". Possibly this command only adds the target for stable, and I couldn't find out how to specify the beta toolchain.
How can I add another (non-default) target for the beta toolchain?
Read the help for rustup target add:
$ rustup target add --help
rustup-target-add
Add a target to a Rust toolchain
USAGE:
rustup target add [OPTIONS] <target>...
FLAGS:
-h, --help Prints help information
OPTIONS:
--toolchain <toolchain> Toolchain name, such as 'stable', 'nightly', or '1.8.0'. For more information see
`rustup help toolchain`
Thus you want:
rustup target add i686-pc-windows-msvc --toolchain beta
I believe it will add the target to the "current" toolchain by default, so you could also do:
rustup override set beta # in your project directory
rustup target add i686-pc-windows-msvc #
cargo build # no more +beta
rustup target list even displays it as "installed"
Read the help for rustup target list:
$ rustup target list --help
rustup-target-list
List installed and available targets
USAGE:
rustup target list [OPTIONS]
FLAGS:
-h, --help Prints help information
OPTIONS:
--toolchain <toolchain> Toolchain name, such as 'stable', 'nightly', or '1.8.0'. For more information see
`rustup help toolchain`
Thus you want:
rustup target list --toolchain beta
Apart of installing a new target described in the answer above, you might also need to setup your new installed target as a default target.
In order to check all available or installed targets you use:
rustup target list
You can also check your default target by executing:
rustup default
If you want to change the default target you can use the following command:
rustup default <YOUR_TARGET_NAME>
for example: rustup default stable-x86_64-pc-windows-msvc
Also if you need to change a default target to your specific directory, you can create a file with name rust-toolchain and include the target name as a content:
stable-x86_64-pc-windows-msvc
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).