Otherwise when running -386 and -amd64 on the same machine
with both copies of TDM-GCC installed (the installer wizard lets
you choose which one, and you can do both options in two
different install attemps), one previously got this error when
using the 64-bit gcc with a 386 build:
--- FAIL: TestStdcallAndCDeclCallbacks (0.12s)
panic: Failed to load C:\Users\WINDOW~1\AppData\Local\Temp\1\TestCDeclCallback960696761\test.dll: %1 is not a valid Win32 application. [recovered]
panic: Failed to load C:\Users\WINDOW~1\AppData\Local\Temp\1\TestCDeclCallback960696761\test.dll: %1 is not a valid Win32 application.
goroutine 81490 [running]:
runtime.panic(0x5b8c00, 0x1390d4e0)
c:/gobuilder/windows-386-gce-b24422c8828f/go/src/pkg/runtime/panic.c:130 +0xed fp=0x12d99f78 sp=0x12d99f24
testing.func·006()
c:/go/src/pkg/testing/testing.go:421 +0x147 fp=0x12d99fd0 sp=0x12d99f78
----- stack segment boundary -----
runtime.panic(0x5b8c00, 0x1390d4e0)
c:/gobuilder/windows-386-gce-b24422c8828f/go/src/pkg/runtime/panic.c:98 +0x17a fp=0x12155e98 sp=0x12155e44
syscall.MustLoadDLL(0x1390b7c0, 0x4a, 0x2)
c:/go/src/pkg/syscall/dll_windows.go:62 +0x6c fp=0x12155eb8 sp=0x12155e98
runtime_test.(*cbTest).run(0x12155f24, 0x1213cc00, 0x1390b7c0, 0x4a)
c:/gobuilder/windows-386-gce-b24422c8828f/go/src/pkg/runtime/syscall_windows_test.go:399 +0x36 fp=0x12155ef4 sp=0x12155eb8
runtime_test.TestStdcallAndCDeclCallbacks(0x1213cc00)
c:/gobuilder/windows-386-gce-b24422c8828f/go/src/pkg/runtime/syscall_windows_test.go:448 +0x28e fp=0x12155fac sp=0x12155ef4
TBR=cmang
R=cmang
CC=adg, golang-codereviews
https://golang.org/cl/141070043
They were from a time before we had the os/exec package, if
memory serves.
Also, make verbose also mean that the main build's stdout
and stderr go to the real stdout and stderr as well.
I'll want that for the Docker-based builder.
LGTM=adg
R=adg
CC=golang-codereviews
https://golang.org/cl/135000043
"PATH" and "path" are one and the same environment variable
on windows. We set PATH variable, while "path" is set to its
original value. Windows might use either for the sub-process.
LGTM=adg
R=golang-codereviews, adg
CC=golang-codereviews
https://golang.org/cl/109980043
If we are building, for example, linux/386 on a linux/amd64 machine we want to make sure that the whole build is done as a if this were compiled on a real linux/386 machine. In other words, we want to not do a cross compilation build.
The exception to this rule is when we are doing nacl builds. These are by definition always cross compilation, and we have support built into cmd/go to be able to handle this case.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/74230043
Update golang/go#7372
This slipped into the build in revision 4b4229fc616b.
Thanks to @pierredurand87 for noticing the break.
LGTM=bgarcia
R=golang-codereviews, bgarcia
CC=golang-codereviews
https://golang.org/cl/66670043
Allow builder owners to set CGO_ENABLED to override the logic in cmd/go
LGTM=minux.ma, adg
R=golang-codereviews, minux.ma, adg
CC=golang-codereviews
https://golang.org/cl/63570046
It will save a lot of time for slow builders running on slow SD cards.
LGTM=dave, adg
R=golang-codereviews, dave, adg
CC=golang-codereviews
https://golang.org/cl/63550043
`svn update` would fail if the updated files were in the gcc/libgo or gcc/go/gofrontend because unrevisioned versions of those files had been inserted in the last build of gcc.
R=adg, adg
CC=golang-dev
https://golang.org/cl/14299043
Downloading the GCC repo takes a lot of time and everything works fine if we just store it in the buildRoot and reuse it.
R=golang-dev, adg
CC=golang-dev
https://golang.org/cl/13583045
* Added --tool flag that allows user to specify "gccgo" as the tool to build.
* Added builderEnv struct to abstract away setting up the build.
* Made envv and envvWindows methods of the builderEnv struct.
* Modified Builder.envv() to wrap envv and envvWindows
* Added internal builderEnv in Builder.
R=adg
CC=golang-dev
https://golang.org/cl/13240044
