Skip to content

rustup default doesn't show proper warning when architecture is not compatible #3972

Description

@bombless

Fresh install rustup on my Windows Subsystem for Linux, choose stable-x86_64-apple-darwin toolchain
after installation, run rustc it reports ~/.rustup/toolchains/stable-x86_64-apple-darwin/bin/rustc: 1: Syntax error: "(" unexpected

Or if you choose stable-x86_64-pc-windows-gnu, run rustc after installation,
it reports error: the 'rustc' binary, normally provided by the 'rustc' component, is not applicable to the 'stable-x86_64-pc-windows-gnu' toolchain

Activity

  1. ehuss commented on Aug 23, 2021

    @ehuss
    Contributor

    I think there may be some confusion here. There are two concepts in rustup, the toolchain host, and the standard library targets. It looks like you may have installed toolchains for other hosts, which won't run. You only need to install the toolchain for the host you are running on (so on WSL, it would be stable-x86_64-unknown-linux-gnu). To cross compile, you only need to install the standard library target (rustup target add x86_64-pc-windows-gnu). There is more information at https://rust-lang.github.io/rustup/cross-compilation.html about how to install targets, and https://rust-lang.github.io/rustup/concepts/index.html for more on the different concepts in rustup.

    Just beware that cross compiling from linux to windows or macos is not particularly easy. This recent blogpost contains an overview of how to cross-compile to windows.

  2. bombless commented on Aug 23, 2021

    @bombless
    Author

    Thank you! I'll have a try a few hours later when I can reach my machine.

  3. changed the title [-]rustup cross-compilation installation is broken[/-] [+]`rustup default` doesn't show proper warning when architecture is not compatible[/+] on Aug 26, 2021
  4. bombless commented on Aug 26, 2021

    @bombless
    Author

    rustup run nightly-x86_64-unknown-linux-gnu cargo run --target=x86_64-pc-windows-gnu seems to do the job.

    But I still wonder if it is considerable that we change rustup default a little bit so it can warn incompatible architecture

  5. workingjubilee commented on Sep 8, 2021

    @workingjubilee
    Member

    That would be a rustup bug. Could this issue be transferred?

  6. ChrisDenton commented on Jul 30, 2024

    @ChrisDenton
    Member

    Attempting to transferr to rust-lang/rustup since this is an issue with the rustup tool...

    @rustbot transfer rustup

  7. transferred this issue fromrust-lang/ruston Jul 30, 2024
  8. added this to the 1.28.0 milestone on Aug 3, 2024
  9. rami3l commented on Aug 3, 2024

    @rami3l
    Member

    FWIW we do emit this warning for rustup toolchain install:

    error!("DEPRECATED: future versions of rustup will require --force-non-host to install a non-host toolchain.");
    warn!("toolchain '{name}' may not be able to run on this system.");
    warn!(
    "If you meant to build software to target that platform, perhaps try `rustup target add {}` instead?",
    target_triple.to_string()
    );

    > uname -mrs
    Darwin 23.5.0 arm64
    
    > rustup toolchain install stable-unknown-linux-gnu --profile=minimal
    error: DEPRECATED: future versions of rustup will require --force-non-host to install a non-host toolchain.
    warn: toolchain 'stable-unknown-linux-gnu' may not be able to run on this system.
    warn: If you meant to build software to target that platform, perhaps try `rustup target add aarch64-unknown-linux-gnu` instead?
    info: syncing channel updates for 'stable-aarch64-unknown-linux-gnu'
    info: latest update on 2024-07-25, rust version 1.80.0 (051478957 2024-07-21)
    info: downloading component 'cargo'
    info: downloading component 'rust-std'
    ^C⏎                           

    ... it could be that this is not covered by rustup default somehow. So adding the same warning to that path should address this issue.

  10. rami3l commented on Aug 3, 2024

    @rami3l
    Member

    async fn default_(
    cfg: &Cfg<'_>,
    toolchain: Option<MaybeResolvableToolchainName>,
    ) -> Result<utils::ExitCode> {

    ... calls:

    pub async fn install_if_not_installed(

    ... so it looks like extracting the warning to a separate function and call it at the beginning of install_if_not_installed() above will do.

    However, this function clashes with Cfg::ensure_installed, so it's better to unify them. I'll have a look later...

  11. self-assigned this
    on Aug 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions