x/build: update C compiler on Windows builders to a currently-maintained version #35006
Comments
No worries. I will try to have a go at this myself. When I have time. Alex |
dmitshur
added
the
NeedsFix
|
I'd recommend using the ones from https://musl.cc/ . They're up to date and work very well: http://musl.cc/x86_64-w64-mingw32-native.zip I mirror the snapshot that I use for WireGuard here, if you'd prefer to grab a build that's been "battle-tested": https://download.wireguard.com/windows-toolchain/distfiles/x86_64-w64-mingw32-native-20190903.zip |
I tried running all.bat on the current tip against
and it all passes. While, if I do the same against
it fails in debug/pe with error similar to #23649 (comment) Why is that? And, while I, probably, prefer your version of gcc, our builders should test against what most users use. Alex |
|
I'll CC @zv-io to talk about why the musl.cc compilers are better. Usually those compilers are up to date and use recent MingW that fixes bugs.
We should direct users to using actually maintained compilers. Windows toolchains are a moving target, and those old ones have many problems. |
I am all for making better tools available to Go users. But we still need to fix bugs that Go users experience while using whatever tools they use. How do you propose we handle bugs like #23649 if we don't use same compilers as #23649 users? Alex |
I have no interest adding hacks to Golang to work around known bugs in ancient compilers that aren't supported by Microsoft in the first place. It would be one thing if we supported MSVC and there was a bug there we have to deal with. But here we're talking about some random compilers people download from Sourceforge. I won't waste my time fighting with that junk. Rather, most of these things have been fixed upstream already, and @zv-io is nice enough to make builds available at musl.cc. |
|
Hi, I maintain these.
I can't explain why the other toolchain causes the error, and the build log referenced by that comment is nonexistent. I'm having a hard time finding information about how those toolchains are built. I use the latest MinGW-W64 when I prepare each release, and provide recipes and build scripts for all releases.
There's #23649 (comment) which maybe someone else can advise on, but I'm going to agree with @zx2c4 that it's entirely a waste of time to figure out how to hack around bugs in broken toolchains. Further, not encouraging their use might reduce your maintenance burden, not add to it. I'm guessing that "most users" won't complain about using up-to-date, reproducible toolchains that don't require JavaScript or advertisements to download. They even work on Windows XP. |
This is what all Go users use. Including our builders (see https://github.com/golang/go/wiki/WindowsBuild ). If we are to change this, then we should all agree what Mingw we use. Perhaps we should even provide the url in https://golang.org/doc/install - if there are many Mingw versions and they work differently, then we should be explicit there. And we should update our builders to run the same software. I am fine using http://musl.cc if everyone agrees. @rsc and @ianlancetaylor ? And we won't be fixing issues like #23649, because they are not reproducible with http://musl.cc . @mattn can you, please, verify? I used http://musl.cc/x86_64-w64-mingw32-native.zip
@zv-io thank you for taking time to comment here. The fix for #23649 is here https://go-review.googlesource.com/c/go/+/197977/ And the gist of the fix is, it works around commit b295099 from git://git.code.sf.net/p/mingw-w64/mingw-w64 Does your Mingw build includes this commit? The commit (as I understand it) adds Alex |
|
Change https://golang.org/cl/203603 mentions this issue: |
|
@rsc and @ianlancetaylor The MINGW gcc our builders use is very very old. We need to decide on the replacement - see my comment #35006 (comment) and whole thread in general. What do you think? Thank you. Alex |
I checked this compiler.
All works fine. And -race too. |
|
I recently had to set up a Windows machine to compile Go (with cgo) from source and it was a truly awful experience. I somewhat managed to hit every single issue and incompatibility between windows, cgo and several versions of gcc/cygwin/mingw/mingw-w64/msys/TDM-GCC that was ever reported on the issue tracker. At some point I had probably half a dozen GNU toolchains installed, all giving me a different combination of errors, crashes, and gcc warnings when running At the end I was able to find some installer that downloaded and unpacked a mingw-w64 toolchain that was miraculously able to make a cgo-enabled So yes, let's settle on some maintained, up-to-date GNU toolchain distribution for Windows, bless that one, and document it in
So that people using cgo or building Go from source on Windows know what GNU toolchain they are supposed to put on their machine. Anyway after finding this thread I nuked all the GNU toolchains I had and tried the musl.cc linked above and it worked just fine. I like that
|
bcmills
changed the title
|
Per #50824: According to the GCC release history, 5.1.0 was released April 22, 2015, nearly seven(!) years ago. There have been subsequent maintenance releases up to GCC 5.5 (Oct. 10, 2017), and no apparent active maintenance since then. The GCC flags required for reproducible builds are only available as of GCC 8 or higher, so having such an antiquated compiler on the Windows builders means that we cannot test cgo-enabled builds for reproducibility on the builders. The builder image needs a few other updates for adequate test coverage as well (see #46693), so we should probably refresh Going forward, I would like to see us have a consistent plan for keeping builder images up to date. While it may be important to test against very old compilers, in general we expect users to work around platform bugs by upgrading their platform to fix those bugs — so it is even more important that we test against up-to-date platforms, especially on the |
|
I would like to make build reproducibility a priority for 2022. Marking as release-blocker for Go 1.19, and I will have a separate conversation with the release team to make a plan to resolve this. |
This patch reworks the handling of DLL import symbols in the PE host
object loader to ensure that the Go linker can deal with them properly
during internal linking.
Prior to this point the strategy was to immediately treat an import
symbol reference of the form "__imp__XXX" as if it were a reference to
the corresponding DYNIMPORT symbol XXX, except for certain special
cases. This worked for the most part, but ran into problems in
situations where the target ("XXX") wasn't a previously created
DYNIMPORT symbol (and when these problems happened, the root cause was
not always easy to see).
The new strategy is to not do any renaming or forwarding immediately,
but to delay handling until host object loading is complete. At that
point we make a scan through the newly introduced text+data sections
looking at the relocations that target import symbols, forwarding
the references to the corresponding DYNIMPORT sym where appropriate
and where there are direct refs to the DYNIMPORT syms, tagging them
for stub generation later on.
Updates #35006.
Updates #53540.
Change-Id: I2d42b39141ae150a9f82ecc334001749ae8a3b4a
Reviewed-on: https://go-review.googlesource.com/c/go/+/451738
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
|
Latest status. Following most recent CL stack the "newcc" canary builders are all passing, with the exception of windows-amd64-2008-newcc: The failures above are with external linking, not internal linking. From what I can tell from googling, "exit status 0xc0000139" is basically a windows loader error; the dynamic loader is unhappy with the binary and won't let it start. Strangely, I can run the binary on linux using "wine64", and the internally linker versions work fine, so I think this looks more like a bad interaction between the new compilers and the older (2008 vintage) of windows. I will try to do some more detective work to see what it is that is triggering the problem. |
|
Change https://go.dev/cl/452675 mentions this issue: |
I accidentally reverted its edits with a bad cherry-pick in CL 452457. This should re-fix the windows-.*-newcc builders that regressed at that change. Updates #47257. Updates #35006. Updates #53540. Change-Id: I5818416af7c4c8c1593c36aa0198331b42b6c7d7 Reviewed-on: https://go-review.googlesource.com/c/go/+/452675 Run-TryBot: Bryan Mills <bcmills@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Auto-Submit: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
|
I've filed a separate issue for the "2008 version of windows" + race detector + external linking + newer compilers problem: #56904 |
|
Change https://go.dev/cl/453095 mentions this issue: |
Revamp the setup for windows-amd64 and windows-386 builders so that we default to using newer C compilers for Go 1.20 and main branch, but older compilers for release branches (1.19 and prior). Instead of having a series of "newcc" canary builders for windows, we now have a series of "oldcc" builders for release branch use. Note for posterity: we can prune these changes out in a couple of Go release (once Go 1.20 becomes the oldest release we're testing). Updates golang/go#35006. Change-Id: I329b59a5d67c2c1ae65a30564a1c6a081b2523fa Reviewed-on: https://go-review.googlesource.com/c/build/+/453095 Reviewed-by: Heschi Kreinick <heschi@google.com> Run-TryBot: Than McIntosh <thanm@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
|
Change https://go.dev/cl/420197 mentions this issue: |
|
Update: we now have new compilers (LLVM-14 based) on our golang 386 and amd64 build farm machines. I am going to go ahead and close out this bug. |
|
Change https://go.dev/cl/454098 mentions this issue: |
….18/1.19 Select the *-oldcc variants for windows 386/amd64 builders for when building 1.18/1.19 minor releases. This syncs up relui with similar changes in the dashboard (e.g. CL 453095). For golang/go#35006. Change-Id: I1df3fef9459ca23593571448129eb1d1497c4529 Reviewed-on: https://go-review.googlesource.com/c/build/+/454098 TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Than McIntosh <thanm@google.com> Reviewed-by: Heschi Kreinick <heschi@google.com>
|
So, what is the supported gcc version for building Go from source on windows? |
|
Your question is about "building Go from source on windows"-- are you asking about building Go applications (which may use CGO and/or the race detector)? Or about just building Go itself? For the latter question (just building Go itself from source): The C compiler requirements/needs for just building Go itself are pretty minimal; any version of GCC from around 5.x or clang LLVM 8.X or later should work. For the former question (building Go applications that use cgo, -race): If you are building a windows Go application that uses CGO, then of course the requirements on the compiler will depend on what your embedded C code needs. Prior to 1.20, the Go linker was unable to digest some of the trickier elements inside object files produced by more modern C compilers, so for these versions (1.18 and 1.19) the rule was (and still is) to stick to a very old version of GCC (5.x). With 1.20 (which is scheduled for release this coming February), the Go linker has been upgraded to do a better job handling the newer objects, so you should now be able to use more modern versions of GCC and clang. I've tested clang based on LLVM 11 and 14, but later versions of GCC should work as well; if not, please file an issue. Once we upgrade the race detector runtime to the tsan V3 version (the plan is for this to happen not in 1.20 but early in 1.21) you will no longer be able to use the old 5.X GCC version, you'll need to switch to a more modern C compiler version, something that supports HTH. |
How do I install Windows C compiler if I want to build simplest CGO example? I searched the https://go.dev website. And the only useful reference I find is on https://go.dev/doc/install/source that says
But there is no standard method of installing C compiler on Windows. I think we should provide some instructions or links about how to install C compiler that Go Team will support. Thank you. Alex |
|
Change https://go.dev/cl/454504 mentions this issue: |
|
Change https://go.dev/cl/455535 mentions this issue: |
Pass -Wl,--no-insert-timestamp to the external linker on windows, so as to suppress generation of the PE file header data/time stamp. This is in order to make it possible to get reproducible CGO builds on windows (note that we already zero the timestamp field in question for internal linkage). Updates #35006. Change-Id: I3d69cf1fd32e099bd9bb4b0431a4c5f43e4b08f3 Reviewed-on: https://go-review.googlesource.com/c/go/+/455535 Run-TryBot: Than McIntosh <thanm@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
Now that we have newer C compilers on the Windows builders, they should fully support reproducible builds. Updates #35006. Change-Id: I0a8995fe327067c9e73e5578c385ea01ae5dee5d Reviewed-on: https://go-review.googlesource.com/c/go/+/454504 Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Bryan Mills <bcmills@google.com>
Hi, Sorry for the late reply. I mean for building Go from source. Not the apps, but the Go compiler and toolchains. I currently have to stick to gcc 5.1.0 in order to build and pass all tests. Using newer gcc causes all sort of problems. So back to my question, after this update, what is the latest compatible gcc version for building Go compiler and toolchains on Windows? It would be nice to put that information in the "Building Go From Source" documentation. Thanks. |
|
Testing new versions of GCC for Golang is not something one can do at the push of a button, it takes some doing, and potentially has to be done for all of the various
This is certainly the case for 1.18 and 1.19, but should no longer be true for Go 1.20 (tip) for windows. The current golang windows 386/amd64 builders are now at clang version 14, if that helps. |
Revise the recipe for building a windows race syso slightly to use the existing compilers on the windows machine (in C:\godep\gcc64\bin) as opposed to downloading GCC 5.X via "choco install". This requires updating PATH following the refresh env. Updates golang/go#35006. Updates golang/go#53539. Change-Id: I14c8491159f421f688f8d4b7c84250768d69ea42 Reviewed-on: https://go-review.googlesource.com/c/build/+/414475 Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
When testing a change to the Go repo that is needed to help build/test
a new version of the race detector, it helps to be able to do a
racebuild run from a specific Go revision plus a cherry-picked CL on
top of that revision. This patch adds a new flag ("-cherrypick") to
support that, also a "-checkout" that can be used to check out a
stack of pending changes on Gerrit.
Updates golang/go#35006.
Updates golang/go#53539.
Change-Id: Id6c508f21e11a445c89df8457dc6a65020eee0fb
Reviewed-on: https://go-review.googlesource.com/c/build/+/415674
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
When debugging new versions of the race detector runtime, it can be useful to copy the newly built syso back to the local machine's Go repo (from the gomote) even if race.bat/race.bash fails, so as to analyze the syso or run other tests with it. Add a command line option "-copyonfail" that attempts to perform the copy even if the script run fails. Updates golang/go#35006. Updates golang/go#53539. Change-Id: I688b8673b444d1b6d948f10ca2fa4ab109eade44 Reviewed-on: https://go-review.googlesource.com/c/build/+/415675 Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
Update race_windows_amd64.syso to latest tsan (V3) runtime. This version of the runtime depends on libsynchronization.a, so to use this syso, you need to also be using a sufficiently up to date version of GCC (notably GCC 5.1, installed on the Go windows builders right now, does not include this library). Updates #48231. Updates #35006. Fixes #49761. Change-Id: Ia1e2b1d8fe7e2c99728150734935a2c522006caa Reviewed-on: https://go-review.googlesource.com/c/go/+/420197 Reviewed-by: Keith Randall <khr@google.com> Run-TryBot: Than McIntosh <thanm@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
Builders and try-bots have gcc 5.1 installed on them. According to https://sourceforge.net/projects/mingw-w64/files/ we could get gcc 8.1.
I discovered problem with our builders while fixing #23649. For example, current debug/pe tests fail, if gcc 8.1 is used, but pass fine on our builders. CL 197977 fixes broken debug/pe tests, but I cannot even verify it on builders / try-bots.
I propose we install gcc 8.1 so we can test #23649 fix, and keep it fixed. gcc 5.1 is many years old, we should use recent gcc on our builders.
I used these files from https://sourceforge.net/projects/mingw-w64/files/
amd64 and 386 versions. I am not sure, if I used correct versions, but they seems to work with my change. I am happy to use any alternative location / version - as long as it is recent. @mattn maybe you have suggestions which mingw version to use.
I also am not sure what to do about old gcc 5.1 installed on our builders. Perhaps we should have both old and new gcc versions installed onto our disk images. And then have different builders use different gcc versions. For better coverage. I noticed that
golang.org/x/build/cmd/buildlet.windowsPathadds gcc bin directory to the path, perhaps we could adjust that code.@bradfitz can you help?
Thank you.
Alex
The text was updated successfully, but these errors were encountered: