Not working on Windows 10. #736
Comments
|
Unfortunately, we don't support Windows builds yet, but we hope to add support soon. The logic for this is in go/private/repository_tools.bzl if you want to experiment with this sooner. |
|
I have done most of the work that I can to get us to the point where we could support windows, and I would like to finish it, but I don't currently have a windows machine to finish it on. It should be really easy (less than a day of effort) to get the core rules working. |
|
@ianthehat I would be interested in testing and possibly contributing in order to make the Go rules (and, if possible, gazelle) work on Windows 10. How can I help? |
|
Run a build on a windows machine and tell me what does not work :) If you are not confident trying to make those changes, try a build and tell me the error message (it will say what the host os is reported as) and then I can make a PR for you to try. |
|
I added those changes and a few more that I found necessary while experimenting. I've reached the point where gazelle can be built, but I get the error message (the "Not a file" error is an indicator for a missing .exe somewhere), but I haven't been confident on where to add .exe for the gazelle binary. Could you give me a hint there? |
|
There are two places, one for fetch_repo and one for gazelle |
|
I added the extension in those places, but still it tries to call gazelle without .exe. cf. 87d000c Where else could I look? What could I do to debug? |
This could be due to the limitation of Bazel that you currently can only reference source targets from Repository rules. Not sure whether |
|
Yes, sorry, I was not clear. The |
|
I encountered this problem as well. Is there a way to do a OS check in go_repository.bzl as well for the labels for _fetch_repo and _gazelle? All my attempts so far have failed. (Adding .exe manually at least helps executing the binaries, which leads to different problems. More about that tomorrow... ;)) |
|
You could try doing this |
|
That works in fact. Thanks so far. Now the gazelle binary is actually executed. :) |
|
I fixed the aforementioned problem. Now gazelle is executed properly. When building though, there's another error, which appears to come from the buildtools. Could that be a problem in the go rules, or should I rather report it to buildtools? |
|
@Xjs that error is in buildtools. It looks like they already have a stub implementation for Windows, but it's not included in their BUILD.bazel. Re-running Gazelle there should fix it. |
|
In order to get a step further, I created a fork of buildtools which works on Windows, and referenced it in repositories.bzl. Now I get a little farther, but now I end up with this error: The mentioned It appears the keys in the |
|
if you do does it work and what does it say? |
|
Seems similar to, but not the same as bazelbuild/bazel#3620 |
|
Doesn't work out of the box, following error: I can't look into it right now, but I can have a closer look on Monday. |
|
Sorry, I broke it with the toolchain changes, fixed in #817 and has a test now. |
|
I tried again with 4781bcc, and now I get the same "Rlocation failed" error as with gazelle before: |
|
I am working on a Windows laptop for a couple of days, if you want to put up what you have so far in a PR, I can see what I can do with it |
|
Thanks. :) #821. |
|
@ianthehat I saw you merged analogous fixes to my PR. Have you made any progress so far? Is there anything else I can do to help? |
|
I also had to do this in order to get anything to work on the laptop I was working on, but there seem to be many possible values for cpu that represent windows, which is going to make this hard. With this, I managed to build a pure go binary, but cgo was not working. If you want to try it (possibly with the change shown above) and let me know what it's doing now... I now have a windows laptop assigned to me so I can keep working on this, but right now it is behaving very differently to the other windows laptop I was workign on, so I am trying to work out why. |
|
I'm quite at loss here -- I created a Hyper-V VM with Windows 10 (Enterprise evaluation edition from TechNet) in order to have an as clean installation as possible. Installed chocolatey, chocolatey-installed git and bazel, cloned a small (testing) go repository and added a WORKSPACE and a BUILD.bazel as in the README file, referencing my local clone that's on the state of b3b0d1e plus my custom buildtools modification. Now I get a slightly different error message whose origin I can't seem to find: |
|
I just tried with |
|
Hey, I have an interest in getting this working. I want to use bazel to build a cross-platform game. @filipesilva, I believe @dslomov was referencing 0.8.0 of rules_go, and you're showing 0.8.0 of bazel :). I no longer experience the C:\WINDOWS tmpdir issue with 0.8.0. I'm now trying to build a package that uses cgo. Following https://docs.bazel.build/versions/master/windows.html#build-c , I set BAZEL_VC and BAZEL_VS like so (using powershell): but when building my package, I'm hit with this: The problem seems to be in stdlib.bzl, since "C:\Windows..." doesn't start with "/" |
|
I followed some of the advice in #1007 (comment); Now I can get further, actually invoking the C compiler: |
|
No I meant 0.8.0 of Bazel. |
|
I am fixing things that will help, as they relate to other bugs (the way we depend on stdlib and the way it gets compiled), and hoping to get back to fixing windows before christmas (as soon as cross compiling cgo is working) |
Sure, |
|
Yes, you can try the GCC toolchain within MSYS by adding |
|
Relating to #1007 (comment) also -- I seem not yet to be getting gcc to work on Windows. The error I mentioned in #1007 occurs with |
|
@dslomov opened PR #1149 , I'm not very happy with it but it got me further. Understood on restriction to GCC, that's fine by me. I've been plugging away, here are some of the outstanding issues I have:
|
|
You probably need to pass |
|
An update from me: I tried with HEAD (329d8f4) and got through to the invocation of gcc with
Any ideas as to where the question mark comes from? Full output: |
|
We are getting there... but now you have got further than me. I spent yesterday failing to get bazel to be able to run gcc at all on windows... |
|
@ianthehat Earlier I had the problem that I had a mingw64 build of |
|
My most recent attempt just used chocolatey, which is the correct pacman
package?
…On Tue, 19 Dec 2017, 08:31 Jannis Andrija Schnitzer, < ***@***.***> wrote:
@ianthehat <https://github.com/ianthehat> Earlier I had the problem that
I had a mingw64 build of gcc installed in C:/tools/msys64/mingw64/bin/gcc,
but not the msys64 build in C:/tools/msys64/usr/bin/gcc. There are pacman
packages for both. Maybe that does it for you as well?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#736 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA0a0FMqli94vYd8wCGgZVU3dGzJhGBBks5tB7qrgaJpZM4O6KcK>
.
|
|
@ianthehat I have the following repository mirrors for the msys repository: Earlier I had only the following package installed: That one (installing gcc in |
|
I found another problem along the way: rules_go seem to be affected by the GOPATH environment variable. My default setting is GOPATH=$HOME, and if set such, the |
|
You have to use TDM-GCC. I've installed TDM-GCC and, for the time being, hard-coded its path in |
|
We have made progress, in fact, we can build fully working cgo binaries now. |
|
I'll try to make Bazel work with mingw under MSYS |
|
Sent https://bazel-review.googlesource.com/#/c/bazel/+/30290/ to enable mingw toolchain under MSYS. |
|
Hi @ianthehat , there are some discussions about how should we enable the mingw gcc toolchain.
Which one is better from your perspective? |
|
None of the above? |
|
Make sense, I made corresponding changes in https://bazel-review.googlesource.com/#/c/bazel/+/30290/ |
We used to have --cpu=x64_windows_msys for selecting msys gcc toolchain, this is a misuse of --cpu flag. Instead, we should use --compiler flag to select C++ toolchain. For example, --compiler=msvc-cl, --compiler=msys-gcc, --compiler=mingw-gcc After this change, we can use mingw gcc toolchain by following steps: 1. In MSYS, install mingw by `pacman -S mingw-w64-x86_64-gcc` 2. Add /mingw64:/mingw64/bin into PATH 3. build with --compiler=mingw-gcc Related: bazelbuild/rules_go#736 Change-Id: I4b5f77ce0698cfcafefe5d2ab17657f9c9e295d3 PiperOrigin-RevId: 180678829
We used to have --cpu=x64_windows_msys for selecting msys gcc toolchain, this is a misuse of --cpu flag. Instead, we should use --compiler flag to select C++ toolchain. For example, --compiler=msvc-cl, --compiler=msys-gcc, --compiler=mingw-gcc After this change, we can use mingw gcc toolchain by following steps: 1. In MSYS, install mingw by `pacman -S mingw-w64-x86_64-gcc` 2. Add /mingw64:/mingw64/bin into PATH 3. build with --compiler=mingw-gcc Related: bazelbuild/rules_go#736 Change-Id: I4b5f77ce0698cfcafefe5d2ab17657f9c9e295d3 PiperOrigin-RevId: 180678829
|
Closing this old issue as we now have basic support for Windows. Some targets can build on Windows 10, but our support and documentation is far from perfect. The windows tag will track Windows issues now. |
When trying to use
go_binaryon Windows I get:The text was updated successfully, but these errors were encountered: