Skip to content

Conversation

cachebag
Copy link
Contributor

@cachebag cachebag commented Sep 22, 2025

Addresses first mentioned issue in #4421, modifying the install script to default to x86_64-pc-windows-gnu under Cygwin/MSYS when no --default-host is provided.

The second issue requires changes in the compiled rustup-init binary (src/), which is out of scope for now

Copy link
Member

@rami3l rami3l left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you very much :)

However, 4221 is not an issue. Maybe you've got the number wrong?

rustup-init.sh Outdated
esac
done
if [ "$_has_default_host_arg" = false ]; then
set -- "$@" --default-host x86_64-pc-windows-gnu
Copy link
Member

@rami3l rami3l Sep 22, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we consider the possibility of aarch64-pc-windows-gnullvm as well? It's a tier 2 target for now.

cc @ChrisDenton

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm... for arm we should probably not touch the default for now, at least until support for gnu on the target is more mainstream. The gnullvm target was only fairly recently promoted to having host tooling and iirc requires installing llvm tools (instead of gnu ones). We could revisit this in the future.

@cachebag cachebag changed the title fix(install): default to GNU host in Cygwin/MSYS/MinGW environments (#4221) fix(install): default to GNU host in Cygwin/MSYS/MinGW environments (#4421) Sep 22, 2025
@cachebag cachebag force-pushed the cygwin-default-host branch 2 times, most recently from 192531b to a051ee1 Compare September 22, 2025 15:11
@cachebag
Copy link
Contributor Author

cachebag commented Sep 22, 2025

However, 4221 is not an issue. Maybe you've got the number wrong?

@rami3l
Thanks for letting me know! Lmk what else may be needed

@rami3l rami3l self-assigned this Sep 23, 2025
@cachebag cachebag force-pushed the cygwin-default-host branch 3 times, most recently from 072ba3f to f3ccd26 Compare September 24, 2025 14:56
@cachebag cachebag requested a review from rami3l September 24, 2025 14:56
Copy link
Member

@rami3l rami3l left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How is this different from the existing functionality below?

rustup/rustup-init.sh

Lines 425 to 427 in 7365ab7

MINGW* | MSYS* | CYGWIN* | Windows_NT)
_ostype=pc-windows-gnu
;;

@cachebag
Copy link
Contributor Author

cachebag commented Sep 28, 2025

@rami3l

How is this different from the existing functionality below?

I presume that it's essentially the safety net to this, no? The idea here is that the issue at hand was detecting x86_64-pc-windows-msvc instead of x86_64-pc-windows-gnu in Cygwin despite the existing detection. I figured that a blanket override ensures that shell script users on Windows get GNU regardless of detection edge cases.

Do we address/refactor the existing detection instead?

@rami3l
Copy link
Member

rami3l commented Sep 29, 2025

How is this different from the existing functionality below?

I presume that it's essentially the safety net to this, no? The idea here is that the issue at hand was detecting x86_64-pc-windows-msvc instead of x86_64-pc-windows-gnu in Cygwin despite the existing detection. I figured that a blanket override ensures that shell script users on Windows get GNU regardless of detection edge cases.

Do we address/refactor the existing detection instead?

Yes, if this PR is made to address #4421 (comment). I don't have a Cygwin test environment, but the detection seems right already to me, so this PR seems unnecessary in its current state.

cc @ChrisDenton for further verification.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants