Windows Support

[yodaldevoid]

The template uses Windows Server Core as the base image. Nano Server was quickly attempted, but the image did not build correctly, and I didn't put any real time into figuring out why. MSVC and GNU variants are created, though due to licensing issues the MSVC variant should never be pushed to the public Docker Hub. Only Windows Server Core 1809 is supported now as that is the highest version that Github Actions or Travis supports and the Microsoft Build Tools installer doesn't support API versions older than 1709. The GNU variant could be build for older Windows versions, but this currently not implemented.

A big shoutout to @nelsonjchen (sorry for pinging you so much) for his previous work on this which acted as a basis for the eventual implementation.

[sfackler]

On the CI side, I think github actions probably makes sense, and we should probably switch the Linux builds over from Travis while we're at it.

[yodaldevoid]

Shoutout to @nelsonjchen for his previous work on this. It helped a lot when minimizing the dockerfiles.

I've minimized everything as far as possible without breaking something. I've added in this PR dockerfiles for the MSVC and GNU toolchains. Also, I've moved all of the CI builds over to GitHub Actions. It is crazy how easy it is to reuse the entire testing framework is between all of the versions built.

[nelsonjchen]

Could you put "Co-authored-by: Nelson Chen <crazysim@gmail.com>" at the end of the commit messages where I contributed to the Dockerfiles?

[lippertmarkus]

How can we bring this forward?

[yodaldevoid]

@lippertmarkus I think the one open question is if we want to have the MSVC toolchain dockerfile/template in this repo despite the fact that it can currently never be uploaded to Docker Hub.

I could split this PR up so that all changes but the MSVC toolchain can be merged now.

[lippertmarkus]

IMHO it should be enough to state at the Docker Hub page that by using the image one agrees to the terms of the MSVC toolchain. Can you just open an issue at https://github.com/microsoft/Windows-Containers/issues asking whether it's fine to include the toolchain to provide an official Rust image for Windows? I mean this also helps them to further emerge Windows Containers

[yodaldevoid]

@lippertmarkus I will ask, but going off of paragraph four of this official blog post (which is called out in the big wall of text in the MSVC Dockerfile), any Dockerfiles with the MSVC build tools are only meant for personal use or use within a organization. They even explicitly note that you should not upload containers containing the MSVC build tools to a public Docker hub.

[lippertmarkus]

Thanks for sharing. That's interesting as Microsoft is using the Build Tools in their official dotnet framework docker images (https://github.com/microsoft/dotnet-framework-docker/blob/3b2ac5bcda7603b94c0b6399355f3d0c0c1eb512/src/sdk/4.8/windowsservercore-1909/Dockerfile#L21-L30) and that would mean you wouldn't be allowed to use those official images without having a Visual Studio License 😄

Let's see what they're saying.

[lippertmarkus]

I created https://github.com/microsoft/Windows-Containers/issues/102

[yodaldevoid]

I created microsoft/Windows-Containers#102

Thank you for that. My free time suddenly disappeared last week and this feel by the wayside.

[sfackler]

Hey, sorry for dropping this for a while!

The main concern is around the licensing of the VS components as you've been discussing upthread. It seems a bit unfortunate to only publish a GNU-based image as MSVC has been the recommended Windows target for quite a while. If we just can't publish an MSVC image then I guess that's the best we can do, but hopefully the licensing situation is a bit less drastic than that initial post makes it sound :)

[lippertmarkus]

seems like we can't continue this work (see https://github.com/microsoft/Windows-Containers/issues/102) 😞

[yodaldevoid]

seems like we can't continue this work (see microsoft/Windows-Containers#102) 😞

Well, to be specific, we can't upload any Docker image created from the MSVC Dockerfile to Docker Hub. We could keep an example template in this or another repo, which I think has a lot of value. All the other changes made by this PR should be fine, however.

[lippertmarkus]

Without any official image to build rust binaries, I'm now cross-building my Windows container images on Linux instead: https://github.com/rust-lang/docker-rust/issues/30#issuecomment-985261684

[haxtibal]

To my understanding, solving rust-lang/rust#71520 would reopen the door for this PR here.

This PR seems stalled because it depends on vs_buildtools.exe and redistribution of the VS Build Tools is not permitted. In turn, VS Buildtools are required because Rust uses their link.exe as default linker. With rust-lang/rust#71520, VS Buildtools would no longer be required. Instead, Rusts copy of lld would be used. Such an image would be good for public upload.

In most situations it's possible to use lld for x86_64-pc-windows-msvc by now. We could do some preliminary trials by setting

[target.x86_64-pc-windows-msvc]
linker = "rust-lld"

or CARGO_TARGET_X86_64_PC_WINDOWS_MSVC_LINKER="rust-lld".

What do you think?

EDIT: This was probably too optimistic. As @ChrisDenton points out, link.exe is not the only dependency. While most rust-lang/libc functions are provided via ucrtbase (distributed with windows), a few symbols are still required from vcruntime.

[ChrisDenton]

See also this internals thread for an overview. In short, vcruntime may one day be made open source, which would help solve issues such as this, but that day isn't today.