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

x/build: update C compiler on Windows builders to a currently-maintained version #35006

Closed
alexbrainman opened this issue Oct 19, 2019 · 95 comments
Assignees
Labels
Builders x/build issues (builders, bots, dashboards) NeedsFix The path to resolution is known, but the work has not been done. OS-Windows
Milestone

Comments

@alexbrainman
Copy link
Member

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/

https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/8.1.0/threads-win32/seh/x86_64-8.1.0-release-win32-seh-rt_v6-rev0.7z

https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/8.1.0/threads-win32/dwarf/i686-8.1.0-release-win32-dwarf-rt_v6-rev0.7z

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.windowsPath adds gcc bin directory to the path, perhaps we could adjust that code.

@bradfitz can you help?

Thank you.

Alex

@gopherbot gopherbot added this to the Unreleased milestone Oct 19, 2019
@gopherbot gopherbot added the Builders x/build issues (builders, bots, dashboards) label Oct 19, 2019
@bradfitz
Copy link
Contributor

I'm too busy to work on this unfortunately.

/cc @toothrot @dmitshur

@alexbrainman
Copy link
Member Author

I'm too busy to work on this unfortunately.

No worries. I will try to have a go at this myself. When I have time.

Alex

@dmitshur dmitshur added the NeedsFix The path to resolution is known, but the work has not been done. label Oct 21, 2019
@zx2c4
Copy link
Contributor

zx2c4 commented Oct 23, 2019

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
http://musl.cc/i686-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
https://download.wireguard.com/windows-toolchain/distfiles/i686-w64-mingw32-native-20190903.zip

@alexbrainman
Copy link
Member Author

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
http://musl.cc/i686-w64-mingw32-native.zip

I tried running all.bat on the current tip against

http://musl.cc/x86_64-w64-mingw32-native.zip

and it all passes. While, if I do the same against

https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/8.1.0/threads-win32/seh/x86_64-8.1.0-release-win32-seh-rt_v6-rev0.7z

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

@zx2c4
Copy link
Contributor

zx2c4 commented Oct 25, 2019

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.

And, while I, probably, prefer your version of gcc, our builders should test against what most users use.

We should direct users to using actually maintained compilers. Windows toolchains are a moving target, and those old ones have many problems.

@alexbrainman
Copy link
Member Author

We should direct users to using actually maintained compilers.

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

@zx2c4
Copy link
Contributor

zx2c4 commented Oct 25, 2019

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?

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.

@zv-io
Copy link

zv-io commented Oct 25, 2019

Hi, I maintain these.

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
http://musl.cc/i686-w64-mingw32-native.zip

I tried running all.bat on the current tip against

http://musl.cc/x86_64-w64-mingw32-native.zip

and it all passes. While, if I do the same against

https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/8.1.0/threads-win32/seh/x86_64-8.1.0-release-win32-seh-rt_v6-rev0.7z

it fails in debug/pe with error similar to #23649 (comment)

Why is that?

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.

And, while I, probably, prefer your version of gcc, our builders should test against what most users use.

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.

@alexbrainman
Copy link
Member Author

But here we're talking about some random compilers people download from Sourceforge.

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

I can't explain why the other toolchain causes the error,

@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 __imp___acrt_iob_func symbol. That breaks Go internal linker, because Go assumes that all symbols starting with __imp_ live in external DLLs. The bug does not happens with http://musl.cc - I did not investigate it enough to understand why.

Alex

@gopherbot
Copy link

Change https://golang.org/cl/203603 mentions this issue: Revert "cmd/link: use libmsvcrt.a during internal link"

@alexbrainman
Copy link
Member Author

@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

@mattn
Copy link
Member

mattn commented Nov 24, 2019

@alexbrainman

@ mattn can you, please, verify? I used http://musl.cc/x86_64-w64-mingw32-native.zip

I checked this compiler.

  • mattn/go-sqlite3 (sqlite3 driver)
  • mattn/go-tflite (tensorflow lite binding)
  • mattn/go-oci8 (oracle driver)

All works fine. And -race too.

@ALTree
Copy link
Member

ALTree commented Dec 21, 2019

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 make.bat.

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 make.bat run finish with no issues. I don't even know where that toolchain came from and what version of gcc shipped.

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

  • It seems to be maintained and ships a recent GCC version
  • It can be used to run a cgo-enabled make.bat with no warnings whatsoever
  • It's portable (download, unzip, add to path); no installers

@bcmills
Copy link
Member

bcmills commented Jan 26, 2022

Per #50824:
As far as I can tell, the gcc used to run tests on the Go windows-amd64-longtest builders is currently version 5.1.0:

gopher@SERVER-2016-V7- C:\godep\gcc64\bin>.\gcc --version
gcc (tdm64-1) 5.1.0

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 gcc at the same time. (CC @golang/release)

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 -longtest builders.

@bcmills
Copy link
Member

bcmills commented Jan 26, 2022

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.

@gopherbot
Copy link

Change https://go.dev/cl/451816 mentions this issue: misc/cgo/testcshared: handle unsuffixed dlltool path

gopherbot pushed a commit that referenced this issue Nov 19, 2022
Adapt the testcshared tests to handle the case where the path output
by invoking

  gcc -print-prog-name=dlltool

is a path lacking the final ".exe" suffix (this seems to be what clang
is doing); tack it on before using if this is the case.

Updates #35006.
Updates #53540.

Change-Id: I04fb7b9fc90677880b1ced4a4ad2a8867a3f5f86
Reviewed-on: https://go-review.googlesource.com/c/go/+/451816
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
gopherbot pushed a commit that referenced this issue Nov 19, 2022
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>
@thanm
Copy link
Contributor

thanm commented Nov 21, 2022

Latest status.

Following most recent CL stack the "newcc" canary builders are all passing, with the exception of windows-amd64-2008-newcc:

##### Testing race detector
ok  	runtime/race	12.578s
ok  	flag	1.049s
ok  	net	1.104s
ok  	os	1.144s
ok  	os/exec	2.076s
ok  	encoding/gob	1.069s
exit status 0xc0000139
FAIL	flag	0.010s
exit status 0xc0000139
FAIL	os/exec	0.010s
FAIL

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.

@gopherbot
Copy link

Change https://go.dev/cl/452675 mentions this issue: misc/cgo/testcshared: reapply CL 451816

gopherbot pushed a commit that referenced this issue Nov 22, 2022
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>
@thanm
Copy link
Contributor

thanm commented Nov 22, 2022

I've filed a separate issue for the "2008 version of windows" + race detector + external linking + newer compilers problem: #56904

@gopherbot
Copy link

Change https://go.dev/cl/453095 mentions this issue: dashboard: default to new compilers for windows amd64/386 builders

gopherbot pushed a commit to golang/build that referenced this issue Nov 28, 2022
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>
@gopherbot
Copy link

Change https://go.dev/cl/420197 mentions this issue: runtime/race: update race_windows_amd64.syso

@thanm
Copy link
Contributor

thanm commented Nov 29, 2022

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.

@thanm thanm closed this as completed Nov 29, 2022
@dmitshur dmitshur moved this from Planned to Done in Go Release Team Nov 29, 2022
@gopherbot
Copy link

Change https://go.dev/cl/454098 mentions this issue: internal/releasetargets: use *-oldcc windows 386/amd64 builders for 1.18/1.19

gopherbot pushed a commit to golang/build that referenced this issue Dec 1, 2022
….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>
@henryas
Copy link

henryas commented Dec 2, 2022

So, what is the supported gcc version for building Go from source on windows?

@thanm
Copy link
Contributor

thanm commented Dec 2, 2022

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 libsynchronization.a (which GCC 5.X does not).

HTH.

@alexbrainman
Copy link
Member Author

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.

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

To build a Go installation with cgo support, which permits Go programs to import C libraries, a C compiler such as gcc or clang must be installed first. Do this using whatever installation method is standard on the system.

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

@gopherbot
Copy link

Change https://go.dev/cl/454504 mentions this issue: cmd/go: unskip TestScript/build_issue48319 on Windows

@gopherbot
Copy link

Change https://go.dev/cl/455535 mentions this issue: cmd/link: pass -Wl,--no-insert-timestamp to external linker on windows

gopherbot pushed a commit that referenced this issue Dec 6, 2022
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>
gopherbot pushed a commit that referenced this issue Dec 6, 2022
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>
@henryas
Copy link

henryas commented Dec 7, 2022

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 tricker elements inside object filesproduced 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 libsynchronization.a (which GCC 5.X does not).

HTH.

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.

@thanm
Copy link
Contributor

thanm commented Dec 9, 2022

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 { GOOS x GOARCH } combinations. I think speaking for myself I would rather not get into the business of having to test new GCC versions every 3 or 4 months when new ones roll out, so I don't think anyone wants to sign up to maintain the doc page that specifies the "latest compatible GCC version".

I currently have to stick to gcc 5.1.0 in order to build and pass all tests

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.

gopherbot pushed a commit to golang/build that referenced this issue Jan 12, 2023
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>
gopherbot pushed a commit to golang/build that referenced this issue Jan 12, 2023
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>
gopherbot pushed a commit to golang/build that referenced this issue Jan 12, 2023
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>
gopherbot pushed a commit that referenced this issue Jan 25, 2023
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Builders x/build issues (builders, bots, dashboards) NeedsFix The path to resolution is known, but the work has not been done. OS-Windows
Projects
No open projects
Development

No branches or pull requests