Rustup on Windows installs incorrect architecture of Rust by default

[peschkaj]

Using Windows 10 Professional, 64-bit with MSVC installed, Platform set to "X64", and PROCESSOR_ARCHITECTURE set to "AMD64".

Currently, running rustup default stable-msvc (or even specifying an override) without specifying the architecture installs i686-pc-windows-msvc which is incompatible with 64-bit MSVC binaries.

Steps to repro:

mkdir test-rustup
cd test-rustup
rustup override add stable-msvc
rustup show

Output:
stable-msvc (directory override for '\\?\D:\src\test-rustup')

rustc --verbose --version

Output:
rustc 1.7.0 (a5d1e7a59 2016-02-29)
binary: rustc
commit-hash: a5d1e7a59a2a3413c377b003075349f854304b5e
commit-date: 2016-02-29
host: i686-pc-windows-msvc
release: 1.7.0

cd ..
rustup show

Output:
stable-x86_64-msvc (default toolchain)

rustc --verbose --version

Output:
rustc 1.7.0 (a5d1e7a59 2016-02-29)
binary: rustc
commit-hash: a5d1e7a59a2a3413c377b003075349f854304b5e
commit-date: 2016-02-29
host: x86_64-pc-windows-msvc
release: 1.7.0

[brson]

Thanks for the report. Did you expect it to install x86_64-pc-windows-msvc instead of i686-pc-windows-msvc? You can install that toolchain anyway with stable-x86_64-pc-windows-msvc.

You got the i686 MSVC toolchain because the way rustup infers parts of the target spec is based off the target of the running exe (which is i686-pc-windows-gnu). We could possibly change the inference to use the architecture of the host platform instead, but I'm not sure that's better - it's long been my impression that 32-bit development is still a safe 'default' for Windows. So what you are seeing is intended behavior, but it's definitely debatable.

[Diggsey]

One of the features I've wanted for a while is for the default host target to be configurable, which would help avoid this problem.

[peschkaj]

I did expect to install x86_64-pc-windows-msvc. I eventually got it installed using the full platform name, but it took me a second to figure out why a build was failing during the linking phase.

Here's where my expectation comes from: My profile executes vcbuildtools.bat "amd64" during shell launch (the same as using the "Visual C++ 2015 x64 Build Tools" prompt. vcbuildtools.bat injects the Platform and PROCESSOR_ARCHITECTURE environment variables. Basically - everything is set up to build 64-bit exes and libs using MSVC.

I see where you're coming from with 32-bit being the default - that's still relatively safe for many Windows users. I don't know what the right answer is here.

[Diggsey]

Actually, I do think we should provide both 32 and 64-bit binaries from www.rustup.rs

[peschkaj]

@Diggsey do you mean a default set up/install path so that people like me who default to 64-bit MSVC would get a 64-bit MSVC Rust by default?

[Diggsey]

@peschkaj
No, it would just affect how toolchain names are resolved. At the moment, missing components are filled in using the host toolchain, which is why msvc resolves to i686-pc-windows-msvc (assuming the host target is i686-pc-windows-gnu)

The idea is that instead of the host target being hard-coded at compile time (it's currently based off the rust cfg variables) it would be configurable.

[brson]

Here's where my expectation comes from: My profile executes vcbuildtools.bat "amd64" during shell launch (the same as using the "Visual C++ 2015 x64 Build Tools" prompt. vcbuildtools.bat injects the Platform and PROCESSOR_ARCHITECTURE environment variables. Basically - everything is set up to build 64-bit exes and libs using MSVC.

Interesting, so we could detect that you are running in a VC console and automatically pick the 'right' toolchain.

[peschkaj]

@brson - absolutely!

The vcbuildtools.bat for MSVC and (i think) vcvars.bat for VS set these up depending on what the user's running.

It could be confusing if someone were using the VC console for "X64 X86 Cross Build Tools", but even in that case you'll have:

Platform=X86
PreferredToolArchitecture=x64
PROCESSOR_ARCHITECTURE=AMD64

But, yeah, back to your original point - it's totally possible to target the current running environment. Worst case, the user is running in a basic CMD or PowerShell window and then they get whatever the "base" version of Rust is. At that point, 32-bit GCC Rust makes sense.

[pravic]

I have almost similar question about toolchain resolving: why the default environment is gnu?

$ rustup default nightly
info: syncing channel updates for 'nightly-i686-pc-windows-gnu'

[peschkaj]

@pravic: From a conversation on IRC (I think with @steveklabnik), it's historical. In that same conversation, it was mentioned that the "Install Rust" link might default to MSVC at some point in the future, but these are idle conversations that in no way reflect the future of Rust and I am just an innocent bystander with limited powers.

These days, MSVC++ is completely free for open source developers, and the community edition of Visual Studio works just as well, too.

[pravic]

Is there a way to hack rustup to change target resolving priority?

[Diggsey]

@pravic You can download rustup for other targets from here: https://github.com/rust-lang-nursery/multirust-rs#other-installation-methods

[pravic]

@Diggsey thanks! It seems, I reinstalled it from rustup.rs with gnu abi:

Although this build of rustup installs compilers targeting the GNU ABI by default

[starkat99]

Adding to this: I installed rustup from my previous multirust install, and I was surprised when it unexpectedly installed i686-gnu instead of x86_64-msvc by default when I simply tried to install "stable" with no additional target info. Unless I'm remembering improperly, my previous usage of multirust it would use msvc by default (or I configured it to do so or something, I don't remember). It's probably best to default to msvc on windows...and probably 64-bit on 64-bit machine, though that's a little less crucial other than 32-bit msvc hasn't been considered stabilized yet.

[Diggsey]

This will be fixed by #421

[brson]

Host architecture is configurable at install time now.