Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Windows Support #71

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

Windows Support #71

wants to merge 3 commits into from

Conversation

yodaldevoid
Copy link

@yodaldevoid yodaldevoid commented Feb 7, 2021

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.

@yodaldevoid yodaldevoid mentioned this pull request Feb 7, 2021
x.py Outdated Show resolved Hide resolved
@sfackler
Copy link
Member

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 yodaldevoid force-pushed the windows branch 15 times, most recently from f21e944 to 2998932 Compare February 14, 2021 07:36
@yodaldevoid
Copy link
Author

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.

@yodaldevoid yodaldevoid marked this pull request as ready for review February 14, 2021 08:01

FROM mcr.microsoft.com/windows/servercore:1809

SHELL ["powershell.exe", "-NoLogo", "-ExecutionPolicy", "Bypass", "-Command", "$ErrorActionPreference = 'Stop'; $ProgressPreference = 'SilentlyContinue';"]
Copy link
Member

Choose a reason for hiding this comment

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

It looks like golang's image doesn't set -NoLogo or -ExecutionPolicy Bypass: https://github.com/docker-library/golang/blob/master/1.15/windows/windowsservercore-1809/Dockerfile#L10. Do you know why there's a difference there?

Copy link
Author

Choose a reason for hiding this comment

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

I set -NoLogo because I don't see a reason to have the PowerShell version information and copyright info printed at the start of each command as it's just noise.

As for the -ExecutionPolicy Bypass, I think that might be a leftover from another Windows docker tutorial I had followed. I don't see a reason it needs to be kept.

@@ -0,0 +1,72 @@
# escape=`

# IMAGES BUILT FROM THIS DOCKERFILE ARE NOT TO BE SHARED ON PUBLIC DOCKER HUBs.
Copy link
Member

Choose a reason for hiding this comment

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

The intent of this PR is to produce images that are to be shared on public Docker hubs, right?

Copy link
Author

@yodaldevoid yodaldevoid Feb 15, 2021

Choose a reason for hiding this comment

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

I'm not entirely sure at this point. I had completely missed this license issue until I was reading through @nelsonjchen's implementation. This issue was brought up by them before a few years ago and I didn't see any discussion about it.

I see value in providing a dockerfile for a base Rust on Windows image, but I don't know whether this repo is the right place for that. If we do keep this base dockerfile here, we would just need to make sure not to add it to the manifest file.

@nelsonjchen
Copy link

Could you put "Co-authored-by: Nelson Chen <[email protected]>" at the end of the commit messages where I contributed to the Dockerfiles?

yodaldevoid and others added 2 commits February 15, 2021 00:22
This dockerfile cannot be pushed to public hubs due to licensing
restrictions, but we might as well provide the dockerfile for others and
test against it. Please see the comment at the top of the MSVC template
file for more information.

Co-authored-by: Nelson Chen <[email protected]>
@lippertmarkus
Copy link

How can we bring this forward?

@yodaldevoid
Copy link
Author

@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
Copy link

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
Copy link
Author

@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
Copy link

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
Copy link

I created microsoft/Windows-Containers#102

@yodaldevoid
Copy link
Author

I created microsoft/Windows-Containers#102

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

@sfackler
Copy link
Member

sfackler commented Mar 19, 2021

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
Copy link

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

@yodaldevoid
Copy link
Author

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
Copy link

lippertmarkus commented Dec 3, 2021

Without any official image to build rust binaries, I'm now cross-building my Windows container images on Linux instead: #30 (comment)

@haxtibal
Copy link

haxtibal commented Jul 1, 2022

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
Copy link
Member

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.

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.

6 participants