When we were first introducing module mode, CL 163418 moved many of
the tests in misc/cgo/test into their own test binary under testdata
so misc/cgo/test continued to work in both GOPATH mode and module
mode. This introduce a somewhat complicated test driver into
misc/cgo/test. Since the misc/cgo/test test had to invoke "go test" as
a subprocess, this required care to thread any build flags down into
the subprocess. The output from any failures of the sub-process was
also less than ideal.
Now that we don't have to worry about running these in GOPATH mode any
more, this CL moves all of the tests back into misc/cgo/test and drops
the test driver.
There are two slight complications:
- Test41761 was added after this split and has a C type "S" that's
also present in misc/cgo/test itself. We rename that to keep that
test working.
- TestCgo in go/internal/srcimporter now fails to import misc/cgo/test
because misc/cgo/test now contains imports of other "misc" module
packages and the importer it sets up isn't configured to allow that.
We fix this by setting up a build context that's configured for
this.
Preparation for #37486.
Change-Id: I3c4f73540e0482bbd493823cca44b0ce7fac01f3
Reviewed-on: https://go-review.googlesource.com/c/go/+/447355
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This change preserves the ability to test misc/cgo/test in GOPATH
mode, at the cost of indirection through a 'go test' subprocess.
Updates #30228
Change-Id: I08de855e62278d30fa622b2f7478e43dd2ab0e96
Reviewed-on: https://go-review.googlesource.com/c/163418
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
cmd/go links mingwex and mingw32 libraries to every package it builds.
This breaks when 2 different packages call same gcc standard library
function pow. gcc linker appends pow implementation to the compiled
package, and names that function "pow". But when these 2 compiled
packages are linked together into the final executable, linker
complains, because it finds two "pow" functions with the same name.
This CL stops linking of mingwex and mingw32 during package build -
that leaves pow function reference unresolved. pow reference gets
resolved as final executable is built, by having both internal and
external linker use mingwex and mingw32 libraries.
Fixes#8756
Change-Id: I50ddc79529ea5463c67118d668488345ecf069bc
Reviewed-on: https://go-review.googlesource.com/26670
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
