rustup: rustup update fails and erroneously mention no https support in curl

$ rustup update
info: syncing channel updates for 'stable-armv7-unknown-linux-gnueabihf'
error: could not download file from 'https://static.rust-lang.org/dist/channel-rust-stable.toml.sha256' to '/home/pi/.rustup/tmp/kpgqmw7yym237tou_file'
info: syncing channel updates for 'nightly-armv7-unknown-linux-gnueabihf'
error: could not download file from 'https://static.rust-lang.org/dist/channel-rust-nightly.toml.sha256' to '/home/pi/.rustup/tmp/1g8p1l43ph77ahvz_file'
info: checking for self-updates
error: could not download file from 'https://static.rust-lang.org/rustup/release-stable.toml' to '/tmp/rustup-update.c5REq4ZVU3fY/release-stable.toml'
info: caused by: error during download
info: caused by: [1] Unsupported protocol (Protocol "https" not supported or disabled in libcurl)
=> NOT OK

pi@kilabspi02:~ $ curl https://static.rust-lang.org/dist/channel-rust-stable.toml.sha256
6a73d4aa8eccdfe03fdd7ddd84685c8ccba3ca6516db0475197ef40a21686a52  channel-rust-stable.toml
=> OK

pi@kilabspi02:~ $ curl https://static.rust-lang.org/dist/channel-rust-nightly.toml.sha256
2762bdca077d5a227a7950d69676956c2ed92f553d6bbe578138c607a4495f2a  channel-rust-nightly.toml
=> OK

pi@kilabspi02:~ $ curl https://static.rust-lang.org/rustup/release-stable.toml
schema-version = '1'
version = '1.2.0'
=> OK

pi@kilabspi02:~ $ curl --version
curl 7.38.0 (arm-unknown-linux-gnueabihf) libcurl/7.38.0 OpenSSL/1.0.1t zlib/1.2.8 libidn/1.29 libssh2/1.4.3 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smtp smtps telnet tftp 
Features: AsynchDNS IDN IPv6 Largefile GSS-API SPNEGO NTLM NTLM_WB SSL libz TLS-SRP 
=> curl *does* have https

About this issue

Original URL
State: closed
Created 7 years ago
Reactions: 10
Comments: 24 (10 by maintainers)

Commits related to this issue

Do not build OpenSSL with a prefix then move it elsewhere This causes linking failures on most platforms because the pkg-configs are still pointing to the location specified in prefix (as they should... — committed to jelford/rustup.rs by jelford 7 years ago
Auto merge of #1065 - jelford:fix_caching, r=Diggsey Fix OpenSSL linkage by using the final install-directory in the build This PR addresses #1051 by avoiding moving OpenSSL's install-target directo... — committed to rust-lang/rustup by bors 7 years ago
Do not build OpenSSL with a prefix then move it elsewhere This causes linking failures on most platforms because the pkg-configs are still pointing to the location specified in prefix (as they should... — committed to nodakai/rustup.rs by jelford 7 years ago

Most upvoted comments

@wagenet @jelford The workaround of setting RUSTUP_USE_HYPER worked for me! I was able to compile my first rust executable!

korhadris on Apr 14, 2017

@lorenzoi you should be able to just set RUSTUP_USE_HYPER as an environment variable:

export RUSTUP_USE_HYPER=1
...

…but I haven’t been able to verify, so @korhadris might have gone through an extra step.

@tatsuya6502’s workaround of downloading the sources and building yourself should work too if you already have a working rust setup, just note that if you want to run it as an “update” rather than init, it will help to give the executable a different name:

cargo build 
mv target/debug/rustup-init target/debug/rustup # or ln if you prefer
target/debug/rustup

The difference in paths to rustup-init between here and @tatsuya6502’s answer is because of the --release flag he passed to cargo. You can do that, but your build time will probably be a little quicker without it (and i reckon rustup is a sufficiently un-demanding application that you won’t miss the optimisations a debug build skips out).

jelford on Apr 15, 2017

@JonasVautherin If you have an issue like that, please open a fresh report, include the content of that script and any debugging you have, because I do not have access to macos systems.

kinnison on Oct 16, 2020