-
Notifications
You must be signed in to change notification settings - Fork 17.5k
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
cmd/go: build inside a Windows container does not find the sources in mounted volume #18555
Comments
This could be related to #17540. Alex |
A suitable build environment would be a Windows Server 2016 machine in GCE, Azure ... If there is no template with Docker preinstalled, you can follow the docs to install Docker on a Windows Server 2016 Such a server can build Docker images based on these two base images: So if you want to have a look into Nano Server, using Docker would be easier than maintaining a Nano Server directly. But on Azure there also is a Nano Server VM available. The issue with the symlink to |
CL https://golang.org/cl/41834 mentions this issue. |
@StefanScherer , please try https://go-review.googlesource.com/#/c/41834/ Alex |
Thanks @alexbrainman, I already got the gopherbot notification and wondered if I can help test this. Is there any prebuilt binaries with that commit included so I can build a Windows image with it to try it out? |
At least Go 1.8.1 still has the problem
|
@StefanScherer, the patches we're talking about here are for what will become Go 1.9. Go 1.8.1 is from the Go 1.8 branch which was frozen for new development about 6 months ago. There isn't currently an easy way to get Windows binaries for tip. That is #18136. |
@bradfitz Thanks for the pointer. Yes using Go and finding issues and compiling it from source are some completely different things :-) So getting started compiling easier would be a great benefit. Well I did that once for Docker and wrote a first Dockerfile for it as setting up a development machine was hard. For Go it seems pretty easy. FROM golang:1.8-windowsservercore
WORKDIR /compile
RUN git clone https://github.com/golang/go
WORKDIR /compile/go/src
ENV GOROOT_BOOTSTRAP C:/go
ENV CGO_ENABLED 0
RUN cmd /C all.bat OK, some test errors are there, probably not all the tests run well inside a container as well. But I have two binaries:
Just a short feedback if compiling it this way could do the job for testing the latest master branch would be fine. |
If you just want the binaries, just change |
Thanks. So I tried this binary by appending another line to the Dockerfile RUN cp ..\bin\*.exe \go\bin and then running a container with a mounted volume from the host:
So there is another error message with this new go.exe. |
I have created a gist with the output of the build to show the failed tests, but they seem to me unrelated. Only this
might be interesting. |
I've added the Dockerfile to my dockerfiles-windows repo and let AppVeyor run the same build and test: https://ci.appveyor.com/project/StefanScherer/dockerfiles-windows/build/1.0.469 |
Sorry it is bit long. I hope you can translate it into Docker file or something. I don't know much about how that works. If you want to build current Go tip (or any other version of Go) on clean Windows computer you need:
I suspect you already have git installed. So you just need #2. For #2 you can use any Go version go1.4 and above. It is important to note that #2 binaries should not be listed in your PATH and #2 should not be pointed by GOROOT environment variable. It is GOROOT_BOOTSTRAP should be pointing to the root of #2. The simplest way to get your hands on #2 is to download it from https://storage.googleapis.com/golang/go1.8.1.windows-amd64.zip. I would not use .msi file, because it adjust your PATH and some GO variables. I have downloaded that file and extracted it into C:\a\go1.8.1. Now you can do download current Go tip:
Next thing I always do is create small batch file, like this gocmd.bat:
This file setup all environment variables for you to be able use and rebuild Go tip. I just copy this file to my desktop, I click on it and I get command window I could use to develop. set GOROOT=%MYHOME%\go set GOROOT_BOOTSTRAP=%MYHOME%\go1.8.1 set GOPATH=%MYHOME% set CGO_ENABLED=0 set PATH=%PATH%;%GOROOT%\bin cd %GOROOT%\src CMD Well you click on the file, and once command line opens you should run make.bat to build Go version you have checked out, like:
Once Go is built you can click gocmd.bat again and again, and use your go.exe without running make.bat again. You only need to run it again if you want to checkout different commit and rebuild against new commit. For example to test CL 41834, you would have to run:
and then run make.bat will give you go.exe and all libs as for CL 41834 Patch Set 3. You can do all this exercise outside of Docker, and then pass c:\a into Docker with your "$(pwd):C:\code" trick. That is what I did. I had to copy my gocmd.bat into docker_gocmd.bat and modify MYHOME variable. I also had to set PATH inside docker directly (without using %PATH% trick), because your golang:1.8-nanoserver already adds some Go version to the PATH. You don't want two different go.exe version in your PATH. You can also run make.bat inside Docker. You can also use already installed Go version (from golang:1.8-nanoserver) for GOROOT_BOOTSTRAP. You only have to remember to modify your PATH so that old go.exe is not listed there - you only want go.exe from directory where you're building to be in the PATH.
What Brad said. Do not call all.bat. all.bat builds Go + runs all tests. If people don't develops Go inside Docker, then noone report bugs. So there might be some bugs. Even non-Go bugs :-) Just run make.bat to build Go, and test what you care about.
Looks like you copy go.exe (and others) from one Go tree into the other. Do not do that. make.bat builds your *.exe and *.o and then you use them. You can copy whole tree, but do not mix and match *.exe and *.o from different source trees. It is also important that sources match *.exe and *.o - otherwise go will start rebuilding them automatically to match them.
I said do not do "RUN cp ..\bin*.exe \go\bin", but it somehow worked. This is the error message I saw on current tip. But if you apply CL 41834, you should be able to build your program.
The TestNetworkSymbolicLink uses Server service. And that is not running inside your Docker. Surprisingly, we didn't have anyone complain about this yet. Do not run all.bat. Hope it helps. Alex |
Thank you @alexbrainman for the detailed steps. I've updated my Dockerfile with commit StefanScherer/dockerfiles-windows@195a969, first move away the original /go 1.8.1 inside the base image, then clone and fetch the CL 41834, then build it at /go/src to have the final binaries in PATH /go/bin. With that image I can build in a folder mounted from my Docker host (even from my Mac that hosts my windows-docker-machine VM):
The AppVeyor build also shows a "green" build and test, a compiled webserver.exe can be found on the host. So the CL 41834 solves the problem. 👍 |
Thank you for checking. Alex |
What version of Go are you using (
go version
)?What operating system and processor architecture are you using (
go env
)?What did you do?
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.
I tried to compile Go sources inside a Windows container by mounting the sources from the Windows Docker host into the Windows container.
On the Windows Docker host I did:
Now inside the PowerShell session in the Windows container I did:
What did you expect to see?
It should find the Go source in the folder C:\code and build it.
I know there is #15978 with the fix e65bce7 in Go 1.8. That's why I tried it with the latest version.
What did you see instead?
Some more details about the mounted volume / reparse point
C:\code
in the container:The text was updated successfully, but these errors were encountered: