Add cygwin target.

[Berrysoft]

This PR simply adds cygwin target together with msys2 target, based on @ookiineko 's (the account has been deleted) work on cygwin target. My full work is here: master...Berrysoft:rust:dev/cygwin

I have succeeded in building a new rustc for cygwin target, and eventually distributed a new version of fish-shell (rewritten by Rust) for MSYS2.

I will open a new PR to fix std if this PR is accepted.

[rustbot]

Failed to set assignee to compiler-team: cannot assign: response: {"message":"Not Found","documentation_url":"https://docs.github.com/rest/issues/assignees#add-assignees-to-an-issue","status":"404"}

Note: Only org members with at least the repository "read" role, users with write permissions, or people who have commented on the PR may be assigned.

[rustbot]

These commits modify compiler targets.
(See the Target Tier Policy.)

Some changes occurred in src/doc/rustc/src/platform-support

cc @Noratrieb

[Noratrieb]

r? compiler

[workingjubilee]

This should be x86_64-pc-windows-cygwin, if anything.

[mati865]

I'm not sure if two separate triples are necessary given msys2/MSYS2-packages#3012, but I think there is no solution for having to distinguish between Cygwin and MSYS2 DLL yet.

[Berrysoft]

@workingjubilee

This should be x86_64-pc-windows-cygwin, if anything.

@jieyouxu

Question: why does this need to be empty, that seems wrong?

I will answer these two questions here. Ookiineko chose x86_64-pc-cygwin instead of x86_64-pc-windows-cygwin, and I agree with this choice. The target_os is cygwin but not windows, and msys2 is only an variant (or, target_env, so the original cygwin target has an empty target_env). Here are some advantages of this choice:

• Cygwin is a POSIX-compatible layer on Windows. From an engineering view, it would be more convenient to assume it as "unix" but not "windows". A typical cygwin program uses file descriptor instead of file handle, uses malloc instead of HeapAlloc, and uses fork. Cygwin is not a different native ABI just like MinGW and MSVC, but much like a subsystem.
• Make the maintainer (me) easier. Most code in the std assumes that "windows" is not "unix", and "unix" has it's common ways to do many affairs. For example, RawFd is defined for unix, and RawHandle is defined for windows. If cygwin is defined as an independent unix os, I don't have to change and maintain a lot cfgs to make it work.
• To make others' porting easier. If "cygwin" is added as a new target_os in unix family, most crates only need small changes or even no changes to port to this new target. However, if "cygwin" is added as a new ABI on "windows", the whole environment needs a relative massive change to port to Cygwin. All code with cfg(unix) might need to be changed to cfg(any(unix, target_env = "cygwin")) or even cfg(any(unix, all(windows, target_env = "cygwin"))), and all code with cfg(windows) need to be changed to cfg(all(windows, not(target_env = "cygwin"))). That's too ugly.

Therefore, I would suggest that just treat Cygwin as an Unix OS.

[Berrysoft]

I'm not sure if two separate triples are necessary given msys2/MSYS2-packages#3012, but I think there is no solution for having to distinguish between Cygwin and MSYS2 DLL yet.

Well... To be honest MSYS2 is just a fork of Cygwin, with some user-friendly changes. From the compiler's view, the differences are only

• Linker name
• Runtime lib name

However, the cygwin dll and msys2 dll should not be mixed. They all maintain their own services and layers. It might cause some misc errors when a cygwin exe linked to a msys2 dll trying to call fork.

I add the -msys2 target for convenience. If it's not added, the users of MSYS2 might need to tweak their environment a little bit - symlinking the linkers and libs, maybe.

P.S. I test the cygwin target on MSYS2, actually. I just symlinked the linker and libcygwin.a.

[jieyouxu]

@Berrysoft could you file an MCP for adding these two targets? Usually we wouldn't ask for MCPs for adding Tier 3 targets, but in this case I think it's warranted to allow compiler team members to discuss how to sort out the target_os vs target_env situation for cygwin and msys2 targets (in addition to what to use for the target tuple in lieu of other windows-ish targets). Because it feels to me that with this "treat it as Unix OS" scheme, we might have some issues with "Unix-like but not Unix enough" and "Windows-like but not Windows enough" simultaneously.

For instance, say if I have something that is conditioned on cfg(target_os = "windows") or cfg(not(target_os = "windows")), will the cygwin or msys2 target qualify or not?

[Berrysoft]

we might have some issues with "Unix-like but not Unix enough" and "Windows-like but not Windows enough" simultaneously.

Well, I would say that Cygwin is Unix enough in most times, and also Windows enough all the time (because it is really running on Windows). However, from the development view, I don't think target_os = "windows" should include Cygwin target. cfg(target_os = "windows") usually means

• There are file handles and socket handles, not file descriptors. However, Cygwin uses file descriptors just like other Unix.
• There is CreateProcess instead of fork + exec or posix_spawn. However, Cygwin provides all POSIX methods.
• The filesystem is Windows-like (backslash, drive letters, UNC paths, etc.). However, Cygwin uses Unix-like paths. It even provides /dev and /proc.

Yes, treating Cygwin as Unix has some drawbacks:

• fork is very slow on Cygwin. The unix shells work on Cygwin, but usually slower than WSL1 & WSL2.
• IO is not that fast, compared to native Win32 methods. Cygwin doesn't provide kqueue or epoll, while Windows provides IOCP for high-performance IO. I would say that even basic filesystem IO is not that fast either, but it's fine. Everyone using cygwin or MSYS2 knows that.
• I'm not even sure if X11 still runs well in Cygwin. Some cygwin executables (e.g., mintty) calls Win32 APIs directly to create GUI. If we treat cygwin as unix, the windows-rs crate might need to think how to port for cygwin target... but anyway they need to write some code for a new windows target, isn't it?

Therefore I would say that treating cygwin as unix is better. Cygwin runs on Windows, but it's better for us to not know it's Windows. If we add a new windows-cygwin target, and try to use native Win32 API instead of the POSIX layer provided by Cygwin, then the thing is not that meaningful. I would like "unix code" running on Windows. If a unix program, e.g., fish-shell, could not be compiled to Windows with this target, it would be meaningless.

@jieyouxu Do you still think that I need to file an MCP? It's not hard for me to just opening an issue, but I'm afraid of a large debate, only focusing on whether cygwin is Unix or Windows.

Philosophers have only interpreted the world, in various ways; the point, however, is to change it.

I am going to change it.

[jieyouxu]

Do you still think that I need to file an MCP? It's not hard for me to just opening an issue, but I'm afraid of a large debate, only focusing on whether cygwin is Unix or Windows.

That's exactly why I am requesting an MCP when usually Tier 3 targets don't need to, because this aspect is controversial. I intend to give the MCP some time, but if we fail to reach consensus, I'll re-nominate the MCP for compiler triage meeting to decide how to proceed.

I am going to change it.

That's completely fair. I'd like other compiler team members to vibe-check how this change is made.

[workingjubilee]

hmm. I mean, I can run Windows programs on Linux, but

• that doesn't make my Linux computer have target_os = "windows"
• they don't really need modifications (usually), they either work or don't

[Berrysoft]

MCP opened: rust-lang/compiler-team#826

Zulip: https://rust-lang.zulipchat.com/#narrow/stream/233931-xxx/topic/Add.20new.20targets.20for.20Cygwin.20.28and.20MSYS2.29.20compiler-team.23826

[Kreijstal]

oh wow amazing... now let us wait till mrustc supports it

[Noratrieb]

@Kreijstal I'm not sure why you mean with this. you can bootstrap rustc with mrustc on a different supported platform like Linux and then cross compile that to cygwin and continue from there.

[Kreijstal]

@Kreijstal I'm not sure why you mean with this. you can bootstrap rustc with mrustc on a different supported platform like Linux and then cross compile that to cygwin and continue from there.

yes but doing that requires crosscompiling

[Noratrieb]

sure, cross compilation is a thing that exists and that you should be able to use

[Kreijstal]

sure, cross compilation is a thing that exists and that you should be able to use

but mrustc would avoid crosscompilation, so that we can bootrstap rust from cygwin without it.

[Noratrieb]

sure, but I don't get why anyone would need to wait for that

[Kreijstal]

sure, but I don't get why anyone would need to wait for that

so that I can bootstrap rust from cygwin from gcc :)

[Berrysoft]

so that I can bootstrap rust from cygwin from gcc :)

Not now. The std for cygwin is not merged: #137621 , and you also need to patch LLVM to build for cygwin.

[Ry0taK]

@Berrysoft
I've been trying to compile std for Cygwin by myself, but getting the following error from compiler-builtins:

error: <inline asm>:4:20: expected absolute expression
            .type  __rust_probestack, @function

I can see that you made a fork of compiler-builtins but haven't sent the pull request to the upstream yet. Is this change necessary for Cygwin support?

[Berrysoft]

Oh, yes. Thank you for your reminder. It is necessary for cygwin support.

[Ry0taK]

Oh, so I wasn't wrong with my approach then ;) In that case, I think cc-rs is also necessary. Is it possible to share the setup that you compiled fish-shell for Cygwin? Even after patching the cc-rs, libc and compiler-builtins in Cargo.toml, I'm getting the above error for some reasons...

[Berrysoft]

You also need to patch nix, and fish-shell itself. See here.

[Ry0taK]

Ah, I understand it now, thank you so much!