Open str4d opened 8 months ago
As the breakages aren't currently blocking for me, I'm happy to leave my rustup
installation as-is and do more investigation of it if the rustup
devs think it would be helpful and can tell me what to look for.
I just tried running cargo +1.65.0 --version
to force the override, and got this:
$ cargo +1.65.0 --version
error: no such command: `+1.65.0`
Cargo does not handle `+toolchain` directives.
Did you mean to invoke `cargo` through `rustup` instead?
That got me thinking:
$ where cargo
/opt/homebrew/bin/cargo
/Users/str4d/.cargo/bin/cargo
$ echo $PATH
/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/Library/Apple/usr/bin:/Applications/Wireshark.app/Contents/MacOS:/opt/homebrew/opt/python@3.9/libexec/bin:/Users/str4d/go/bin:/Users/str4d/bin:/Users/str4d/.cargo/bin
$ PATH=~/.cargo/bin:$PATH cargo --version
cargo 1.65.0 (4bc8f24d3 2022-10-20)
So this might be the same root cause as https://github.com/rust-lang/rust/issues/114276#issuecomment-1911446978 - the upgrade breaks however rustup
is configuring the PATH
variable, causing it to be looked up last instead of first.
I initially guessed that rustup
might be configuring my PATH
here:
$ cat ~/.profile
export PATH="$HOME/bin:$PATH"
export PATH="$HOME/go/bin:$PATH"
. "$HOME/.cargo/env"
However, there are two problems with that guess:
PATH
ends with ...:/Users/str4d/go/bin:/Users/str4d/bin:/Users/str4d/.cargo/bin
, but ~/.cargo/env
says that it prepends itself, and that happens after the two prior exports, so that would in theory produce ...:/Users/str4d/.cargo/bin:/Users/str4d/go/bin:/Users/str4d/bin
PATH
instead of the beginning, which indicates that if rustup
is indeed relying on ~/.profile
then there is some wider OS issue causing the PATH
created by ~/.profile
to be appended to the global PATH
, which seems odd...Aha, it's (ironically) path_helper
that is causing this! It is taking the PATH
settings from ~/.profile
and appending them to the default system path. https://gist.github.com/Linerre/f11ad4a6a934dcf01ee8415c9457e7b2 is a great write-up of the problem, and per the ordering that it gives for Zsh, the solution appears to be to put the rustup
environment loader in ~/.zprofile
instead. Moving my .profile
contents there immediately fixed the Go and local binary paths (by causing them to appear twice), but rustup
's is still at the end due to I assume caching. I'll restart my laptop to confirm...
Hmm, restarting did not help. Now it seems I have a different problem:
path_helper
is finding the content of ~/.zprofile
and appending it to then (login-level?) PATH
.~/.zprofile
again on top of that PATH
in the shell.path_helper
path (appearing twice) because they use simple export PATH
s. The rustup
path is not prepended because it uses a script that checks whether its path already exists in PATH
(because it does, because path_helper
appended it).I will have to do more reading to figure out what the correct fix is here, and if there is something rustup
can do to better ensure it behaves correctly on macOS.
Looking at how rustup-init
works, it should be writing to ~/.profile
(because it always writes to the POSIX location) and ~/.zshenv
(because macOS defaults to Zsh since 10.15 Catalina):
https://github.com/rust-lang/rustup/blob/33ad3a4304eeeddc651eea95edb17cc7c6bc88d0/src/cli/self_update/shell.rs#L124-L128 https://github.com/rust-lang/rustup/blob/33ad3a4304eeeddc651eea95edb17cc7c6bc88d0/src/cli/self_update/shell.rs#L193-L206
And indeed I found the . "$HOME/.cargo/env"
line in my ~/.profile
(as mentioned above, when I tried moving it to ~/.zprofile
), and my ~/.zshenv
. Incidentally, I also found my Go and local bin exports in those same two places, so maybe when I set up this computer I just searched for what Rustup changed and added those exports myself to the same places? I don't recall.
I separately note that my Homebrew installation added itself only to ~/.zprofile
, and whatever it is doing, it is managing to get itself prepended to my PATH
instead of appended (which is part of why my Rust installation started breaking: alongside that upgrade from macOS 13.6 to 14.2, I installed a piece of software via brew
that required Rust, so brew
installed the stable Rust toolchain directly, and that now overrides my Rustup installation). What is really interesting is that path_helper
does append it, but then in my PATH
Homebrew is only prepended and does not appear twice:
$ /usr/libexec/path_helper
PATH="/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/Library/Apple/usr/bin:/Applications/Wireshark.app/Contents/MacOS:/opt/homebrew/opt/python@3.9/libexec/bin:/Users/str4d/go/bin:/Users/str4d/bin:/opt/homebrew/bin:/opt/homebrew/sbin:/Users/str4d/.cargo/bin"; export PATH;
MANPATH="/usr/share/man:/usr/local/share/man:/Applications/Wireshark.app/Contents/Resources/share/man:/opt/homebrew/share/man:"; export MANPATH;
$ echo $PATH
/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/Library/Apple/usr/bin:/Applications/Wireshark.app/Contents/MacOS:/opt/homebrew/opt/python@3.9/libexec/bin:/Users/str4d/go/bin:/Users/str4d/bin:/Users/str4d/.cargo/bin
Problem
I installed Rust using
rustup
some time last year (or maybe earlier, I forget) onto a Macbook Air M1 running macOS 13. A few weeks ago I upgraded from 13.6 to 14.2, and since then my Rust installation has been subtly broken in ways I keep discovering.Steps
rustup
on macOS 13.6.Possible Solution(s)
No response
Notes
I first noticed problems when I started trying to cross-compile for iOS targets. See https://github.com/rust-lang/rust/issues/114276#issuecomment-1911446978 for more information (as that issue seems to be the same as mine, so I posted a comment there initially).
I just now noticed that the
rustup
overrides are not working (neither manual notrust-toolchain.toml
), which is why I now think it's arustup
problem rather than arustc
orcargo
problem:Rustup version
Installed toolchains