go/misc/cgo/test/issue8756.go

package cgotest

/*
#cgo LDFLAGS: -lm
#include <math.h>
*/
import "C"
import (
	"testing"

	"misc/cgo/test/issue8756"
)

func test8756(t *testing.T) {
	issue8756.Pow()
	C.pow(1, 2)
}
cmd/link, cmd/go: delay linking of mingwex and mingw32 until very end 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> 2016-08-09 19:06:46 -06:00			`package cgotest`

			`/*`
			`#cgo LDFLAGS: -lm`
			`#include <math.h>`
			`*/`
			`import "C"`
			`import (`
			`"testing"`

misc/cgo/test: simplify for module mode 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> 2022-10-21 13:18:14 -06:00			`"misc/cgo/test/issue8756"`
cmd/link, cmd/go: delay linking of mingwex and mingw32 until very end 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> 2016-08-09 19:06:46 -06:00			`)`

			`func test8756(t *testing.T) {`
			`issue8756.Pow()`
			`C.pow(1, 2)`
			`}`