`cargo` proxy has corrupted arg0 for rustup v1.28 on cygwin

[moosedoc]

Verification

• I searched for recent similar issues at https://github.com/rust-lang/rustup/issues?q=is%3Aissue+is%3Aopen%2Cclosed and found no duplicates.
• I am on the latest version of Rustup according to https://github.com/rust-lang/rustup/tags and am still able to reproduce my issue.

Problem

Running the cargo command results in rustup being ran.
For example, running cargo build results in receiving the error:

error: invalid value 'build' for '[+toolchain]': error: "build" is not a valid subcommand, so it was interpreted as a toolchain name, but it is also invalid. To override the toolchain using the 'rustup +toolchain' syntax, make sure to prefix the toolchain override with a '+'

For more information, try '--help'.

Uninstalling rust completely, rebooting, then installing rust has no effect.

Steps

Run rustup update
Attempt to build a rust project.

Possible Solution(s)

No response

Notes

RustRover does not seem to be impacted.

Rustup version

rustup 1.28.1 (f9edccde0 2025-03-05)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: The currently active `rustc` version is `rustc 1.85.0 (4d91de4e4 2025-02-17)`

Installed toolchains

Default host: x86_64-pc-windows-msvc
rustup home:  C:\Users\***\.rustup

installed toolchains
--------------------
stable-x86_64-pc-windows-msvc (active, default)

active toolchain
----------------
name: stable-x86_64-pc-windows-msvc
active because: it's the default toolchain
installed targets:
  x86_64-pc-windows-msvc

OS version

Windows 11; terminal

[moosedoc]

Running diff $(which cargo) $(which rustup) outputs nothing (i.e. binary matches).
C:/Users/***/.cargo/bin/cargo
C:/Users/***/.cargo/bin/rustup
^the output of each respective which

[ChrisDenton]

Can you say which shell you're using?

[moosedoc]

I'm using zsh, but I'm experiencing it on bash as well.

[ChrisDenton]

If you stat cargo what does it show?

[moosedoc]

stat $(which cargo)

File: /c/Users/***/.cargo/bin/cargo -> rustup.exe
Size: 10 Blocks: 0 IO Block: 65536 symbolic link
Device: 49813,2078 Inode: 23362423066991268 Links: 1
Access: (0777/lrwxrwxrwx) Uid: (1351261/ ***) Gid: (1049089/Domain Users)
Access: 2025-03-06 14:26:23.805024100 -0700
Modify: 2025-03-06 14:26:23.805024100 -0700
Change: 2025-03-06 14:26:23.805024100 -0700
Birth: 2025-03-06 14:26:23.805024100 -0700

[moosedoc]

Running ls -alF ~/.cargo/bin gives this:

[ChrisDenton]

That looks correct. These "proxies" are linked to the rustup binary. It works because when you run cargo, rustup will be invoked with the name the link rather than its real name,

I'm not able to repo this locally. What does uname -a say? Maybe we are using different versions.

[moosedoc]

Interesting, today I learned!

CYGWIN_NT-10.0-22631 ********** 3.5.4-1.x86_64 2024-08-25 16:52 UTC x86_64 Cygwin

[ChrisDenton]

Ah, thanks, I can repo this on cygwin but interestingly not git bash or msys2. This might be a bug in cygwin because using symlinks like this is a common unix pattern. I'm not sure how to report it or ask though.

In any case I think to support cygwin rustup will either need to not use symlinks by default or else have some way to disable them.

For now the workaround I'd suggest is install the old version of rustup (rustup 1.27.1) and prevent automatic updates right after install:

rustup set auto-self-update disable

[wrecklass]

Actually, Cygwin uses Windows Symlinks and Junctions perfectly. It's built into the libraries. My suspicion is that Rustup is getting the command line argument incorrectly from cygwin bash, which I believe is the same bash used in Git Bash.

[ChrisDenton]

msys2 and git bash work fine. I do know that msys2 patches cygwin so it might be an issue that msys2 fixed but didn't upstream.

This is specifically a cygwin issue. It does not work because it passes the realpath of the binary as argv[0]. Simple test case in C:

// argv0.c
int main(int argc, char *argv[]) {
    if (argc > 0) {
        printf("%s", argv[0]);
    }
    return 0;
}

Compile as argv0 then in cygwin's bash:

$ cygwin=winsymlinks:nativestrict ln -s argv0 mylink
./mylink

It will print the path to argv0 instead of mylink.

[ChrisDenton]

cc @Berrysoft would you happen to know more about cygwin here (see above comment). Is the argv[0] symlink behaviour a known bug with cygwin? Msys2 seems to fix it, could that fix be upstreamed in to cygwin?

[Berrysoft]

It's a known bug with msys2, and has been fixed since 2018:
https://github.com/msys2/MSYS2-packages/blob/master/msys2-runtime/0021-Fix-native-symbolic-link-spawn-passing-wrong-arg0.patch

I'm not sure why cygwin doesn't fix it. Maybe it's just because people forgot to upstream it.

[ChrisDenton]

Is there anything we can do to bring this to the attention of people who can upstream it?