go/misc/cgo/testshared/src/exe2/exe2.go

package main

import "dep2"

func main() {
	d := &dep2.Dep2{}
	dep2.W = dep2.G() + 1 + d.Method()
}
cmd/internal/ld: store the libraries a shared library was linked against in a note The motivation for this is the innocuous looking test case that is added. This creates a stack exe -> libdep2.so -> libdep.so -> libruntime.so. The problem comes from the fact that a function from libdep.so gets inlined all the way into exe. This (unsurprisingly) means that the object file for exe references symbols from libdep.so, which means that -ldep needs to be passed when linking exe and it isn't. The fix is simply to pass it -- there is no harm in passing it when it's not needed. The thing is, it's not clear at all in the current code to see how the linker can know that libdep2 is linked against libdep. It could look through the DT_NEEDED entries in libdep2 and try to guess which are Go libraries, but it feels better to be explicit. So this adds another SHT_NOTE section that lists the shared libraries a shared library was linked against, and makes sure the complete set of depended upon shared libraries is passed to the external linker. Change-Id: I79aa6f98b4db4721d657a7eb7b7f062269bf49e2 Reviewed-on: https://go-review.googlesource.com/10376 Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> 2015-05-25 14:51:02 +12:00			`package main`

			`import "dep2"`

			`func main() {`
cmd/compile: do not generate tail calls when dynamic linking on ppc64le When a wrapper method calls the real implementation, it's not possible to use a tail call when dynamic linking on ppc64le. The bad scenario is when a local call is made to the wrapper: the wrapper will call the implementation, which might be in a different module and so set the TOC to the appropriate value for that module. But if it returns directly to the wrapper's caller, nothing will reset it to the correct value for that function. Change-Id: Icebf24c9a2a0a9a7c2bce6bd6f1358657284fb10 Reviewed-on: https://go-review.googlesource.com/23468 Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com> TryBot-Result: Gobot Gobot <gobot@golang.org> 2016-05-27 15:41:55 +12:00			`d := &dep2.Dep2{}`
			`dep2.W = dep2.G() + 1 + d.Method()`
cmd/internal/ld: store the libraries a shared library was linked against in a note The motivation for this is the innocuous looking test case that is added. This creates a stack exe -> libdep2.so -> libdep.so -> libruntime.so. The problem comes from the fact that a function from libdep.so gets inlined all the way into exe. This (unsurprisingly) means that the object file for exe references symbols from libdep.so, which means that -ldep needs to be passed when linking exe and it isn't. The fix is simply to pass it -- there is no harm in passing it when it's not needed. The thing is, it's not clear at all in the current code to see how the linker can know that libdep2 is linked against libdep. It could look through the DT_NEEDED entries in libdep2 and try to guess which are Go libraries, but it feels better to be explicit. So this adds another SHT_NOTE section that lists the shared libraries a shared library was linked against, and makes sure the complete set of depended upon shared libraries is passed to the external linker. Change-Id: I79aa6f98b4db4721d657a7eb7b7f062269bf49e2 Reviewed-on: https://go-review.googlesource.com/10376 Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> 2015-05-25 14:51:02 +12:00			`}`