go/misc/cgo/testshared/testdata/dep2/dep2.go

package dep2

import "testshared/depBase"

var W int = 1

var hasProg depBase.HasProg

type Dep2 struct {
	depBase.Dep
}

func G() int {
	return depBase.F() + 1
}
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-24 20:51:02 -06:00			`package dep2`

misc/cgo/testshared: fix tests in module mode Updates #30228 Change-Id: I5cc739eb9fdfb648ec45e350d43d4cb02e450553 Reviewed-on: https://go-review.googlesource.com/c/163211 Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Jay Conrod <jayconrod@google.com> 2019-02-21 12:17:19 -07:00			`import "testshared/depBase"`
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-24 20:51:02 -06:00
			`var W int = 1`

cmd/link: always read type data for dynimport symbols Consider three shared libraries: libBase.so -- defines a type T lib2.so -- references type T lib3.so -- also references type T, and something from lib2 lib2.so will contain a type symbol for T in its symbol table, but no definition. If, when linking lib3.so the linker reads the symbols from lib2.so before libBase.so, the linker didn't read the type data and later crashed. The fix is trivial but the test change is a bit messy because the order the linker reads the shared libraries in ends up depending on the order of the import statements in the file so I had to rename one of the test packages so that gofmt doesn't fix the test by accident... Fixes #15516 Change-Id: I124b058f782c900a3a54c15ed66a0d91d0cde5ce Reviewed-on: https://go-review.googlesource.com/22744 Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> 2016-05-03 17:23:24 -06:00			`var hasProg depBase.HasProg`

			`type Dep2 struct {`
			`depBase.Dep`
			`}`
cmd/internal/ld: do not depend on local symbols to read a type's gcdata We already read the address of a gcmask/gcprog out of the type data, but I didn't know how many bytes to read. But it turns out that it's easy to calculate, so change to do that. This means that we no longer depend on the local symbols being present, allowing me to strip the shared libraries for distribution and make them a lot smaller. As a bonus, this makes LSym another 24 bytes smaller, down to 296 bytes now. Change-Id: I379d359e28d63afae6753efd23efdf1fbb716992 Reviewed-on: https://go-review.googlesource.com/10377 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-24 22:13:50 -06:00
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-24 20:51:02 -06:00			`func G() int {`
cmd/link: always read type data for dynimport symbols Consider three shared libraries: libBase.so -- defines a type T lib2.so -- references type T lib3.so -- also references type T, and something from lib2 lib2.so will contain a type symbol for T in its symbol table, but no definition. If, when linking lib3.so the linker reads the symbols from lib2.so before libBase.so, the linker didn't read the type data and later crashed. The fix is trivial but the test change is a bit messy because the order the linker reads the shared libraries in ends up depending on the order of the import statements in the file so I had to rename one of the test packages so that gofmt doesn't fix the test by accident... Fixes #15516 Change-Id: I124b058f782c900a3a54c15ed66a0d91d0cde5ce Reviewed-on: https://go-review.googlesource.com/22744 Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> 2016-05-03 17:23:24 -06:00			`return depBase.F() + 1`
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-24 20:51:02 -06:00			`}`