rustup-init chooses wrong toolchain

[david-x64]

I downloaded rustup-init.exe for Windows from here:
https://www.rust-lang.org/tools/install

My host is Windows 10 64-bit.

When I ran rustup-init.exe it detected the default host triple correct as:
x86_64-pc-windows-msvc

But when I agreed to proceed with installation it changed its mind to this instead:
i686-pc-windows-msvc

I will attach the log file (just copied std::cout).

Anyway, not a very big problem.
rust-install.log

I installed the 64-bit toolchain now with like this:

C:\Users\David>rustup toolchain list
stable-i686-pc-windows-msvc (default)

C:\Users\David>rustup toolchain install stable-x86_64-pc-windows-msvc
info: syncing channel updates for 'stable-x86_64-pc-windows-msvc'
471.3 KiB / 471.3 KiB (100 %) 133.0 KiB/s in 4s ETA: 0s
info: latest update on 2019-12-19, rust version 1.40.0 (73528e339 2019-12-16)
info: downloading component 'cargo'
3.1 MiB / 3.1 MiB (100 %) 128.0 KiB/s in 26s ETA: 0s
........
......

[kinnison]

This is fascinatingly wrong yes. I apologise for the difficulty this will have given you. Once you installed the correct toolchain, you'll have wanted to rustup set default-host x86_64-pc-windows-msvc as well, just to ensure that future toolchain setup picks the right one. In the meantime I'll try and work out how this could have happened.

Thank you for your report and log.

[kinnison]

I've chased this through and found the following:

1. The displayed default host triple comes from this expression: https://github.com/rust-lang/rustup/blob/master/src/cli/self_update.rs#L618
2. The message about what it's set to during install comes from here: https://github.com/rust-lang/rustup/blob/master/src/cli/self_update.rs#L770 and suggests that because it's not overridden then specifically it comes from here: https://github.com/rust-lang/rustup/blob/master/src/cli/self_update.rs#L775
3. With a fresh installation, the result of that function call comes from here: https://github.com/rust-lang/rustup/blob/master/src/config.rs#L669

Critically the difference is that in 1, TargetTriple::from_host_or_build() is called whereas in 3 TargetTriple::from_build() is used.

I imagine that you acquired the 32 bit version of the installer, though that seems odd as I'd have expected us to give you the 64bit one if your system identified as 64bit. @pietroalbini does the lambda for win.rustup.rs do bitness detection?

Either way, that discrepancy explains what you saw, now I just need to work out which is more usefully correct -- changing Config's behaviour will mean that there's the possibility people who were relying on the from_build() behaviour will get confused (incl. CI) and changing the behaviour in the setup code instead will instead mean that 64bit users may have to customise their installs.

Clearly one or the other has to change, but let's see if Pietro can tell us why you got a 32bit installer instead of a 64bit one.

[david-x64]

Thanks Daniel, I have corrected the default toolchain on my system via rustup set default-host. Looking forward to experimenting with rust!

And yes, that was my first idea too. But I only found this one download button. So if there is a 64-Bit version, than I was given the wrong installer version. Still it might be nice if the installer would be able to install the best matching toolchain for my system.

My host is Windows 10 64-Bit, and the browser I used for downloading is Firefox 71.0 (64-bit).

I checked the rustup-init.exe file, it is definitely the 32-bit Version.

C:\Users\David\Downloads>dumpbin /headers /nologo rustup-init.exe

Dump of file rustup-init.exe

PE signature found

File Type: EXECUTABLE IMAGE

FILE HEADER VALUES
             14C machine (x86)
               4 number of sections
        5DFCBB5B time date stamp Fri Dec 20 13:15:23 2019
               0 file pointer to symbol table
               0 number of symbols
              E0 size of optional header
             122 characteristics
                   Executable
                   Application can handle large (>2GB) addresses
                   32 bit word machine

[pietroalbini]

does the lambda for win.rustup.rs do bitness detection?

@kinnison well... no, this is the whole lambda:

'use strict';

exports.handler = (event, context, callback) => {
    const request = event.Records[0].cf.request;
    const headers = request.headers;

    if (request.uri === '/') {
        request.uri = '/i686-pc-windows-msvc/rustup-init.exe';
    } else if (request.uri == '/i686') {
        request.uri = '/i686-pc-windows-msvc/rustup-init.exe';
    } else if (request.uri == '/x86_64') {
        request.uri = '/x86_64-pc-windows-msvc/rustup-init.exe';
    }
    callback(null, request);
};

[kinnison]

Okay, in that case I'd suggest that the better approach is to use the from_host_or_build() approach in both cases, which will alter the behaviour slightly for people who were relying on the fact that even on a 64bit system, they'd get a 32bit toolchain by default, but I think breaking those people is better than the current misbehaviour which is lying to people. Does everyone agree?

[aQaTL]

Hit this bug today. Interestingly, if I select to modify the default values and type in the same thing (x86_64-pc-windows-msvc), then it installs the correct toolchain.

[kinnison]

Yeah that follows the logic in the code correctly. I'll decide on the right fix and clear it up today.

[rbtcollins]

Indeed this is a fascinating bug. Given that 32 bit is basically niche at this point, , I think our biggest risk of issues is going to be things like debian multiarch. What would happen there, for instance?

[kinnison]

Multiarch is an interesting question. Rustup uses uname() to determine the host arch and when running a multiarch binary it'll pick up the arch of that binary, so it ought to behave right. Obviously it can be overridden in the same way as for Windows.

[rosti-il]

I also experienced this issue. I've downloaded the rustup-init.exe version 1.21.1 (7832b2e 2019-12-20) from https://www.rust-lang.org/tools/install that actually uses https://win.rustup.rs/ as the download link. It gave me a 32-bit version.

I've found the 64-bit version of rustup-init.exe here: https://rustup.rs/ with actual download link https://win.rustup.rs/x86_64

Also the 32-bit version of rustup-init.exe actually can install the x86_64 version of Rust toolchain on 64-bit Windows as well. You need just chose the option 2 (Customize installation) and press Enter several times, choosing everything default. So this doesn't look mandatory to use a 64-bit version of rustup-init.exe to install x86_64 version of Rust toolchain. However it will install 32-bit version of the rustup.exe and probably of other tools. So the main bug here is that the rustup-init.exe doesn't inform what bit version of rustup it's going to install. Also if it can install both the 32-bit and the 64-bit versions of toolchan why it can't download and install the appropriate version of the rustup and rest of the tools? After all the restup-init.exe is just an installer. I think the 32-bit and the 64-bit versions of rustup-init.exe should be unified into a single 32-bit only (i.e. not multiarch) executable that will ask the user what bit version of the rustup to install or properly detect it by itself. Everything rustup-init.exe installs should be downloaded and not packed into itself.

Also there is a problem in the https://www.rust-lang.org/tools/install webpage that doesn't detect the client's OS correctly and offers a wrong download link. Another problem is that the 32-bit and the 64-bit version of rustup-init.exe have exactly the same name and this can confuse, especially on shared storage. Nobody would check this executable with a tool like dumpbin before the first run.

Reopen this bug please.

[rbtcollins]

The bug is fixed, just not in a release yet - I'm sorry you've also been hit by it.

a985815

is the fix. What this changes is makes sure that we honour the host we're running on appropriately, regardless of whether a 32 or 64 bit windows binary of rustup-init is running. Then self-update will eventually get the ideal build of rustup itself over time too, though that matters much much less.

There are perhaps other issues you are highlighting, but if so please do file new bugs.

FWIW rustup-init and rustup are the same binary, just different names; and they can and do install either toolchain versions already - that is kindof how the bug arose in the first place.