Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
cmd/link: fails to link package having a .syso file when using external linker #33139
Being able to inclue a .syso file in a package is great. A Go program using that package works well when that program is linked using the internal linker. Link is however broken when the that program is linked using the external linker, for example, because the Go program also uses cgo.
What version of Go are you using (
#29253 is different because of Cgo and the
Relocations for package
Dissassembly for Cgo wrapper before relocations (from within the Go object file cited above), where you can clearly see the
Disassembly of final executable, after relocations (filtered):
Thanks. The difference is that in cmd/go/testdata/script/cgo_syso_issue29253.txt, the symbol in the syso is only referenced from C code, not Go code (including Go assembly). Here the symbol in the syso is directly called from Go assembly.
In general, calling external functions directly from Go (including Go assembly) is discouraged. But I'm not sure we want to reject it here, given that internal linking works. But it is also possible that this is not a "supported" feature so we don't fix.
As a workaround, you can force internal linking by passing
This kind of direct access is not only advertised on the Go Wiki since 2014, but is an extraordinarily useful feature for executing performance-critical code that is not written in Go, and where the overhead of using cgo is to be avoided where possible.
Yes -- internal linking works, but so does external linking with a
Sadly that is not a valid workaround:
This reverts CL 186417. Reason for revert: Broke darwin (10_14), linux (ppc), aix (ppc) Updates #33139 Change-Id: I8bf3c817a96a0e57e45754a097cea7062b2fcdfd Reviewed-on: https://go-review.googlesource.com/c/go/+/198177 Run-TryBot: Andrew Bonventre <email@example.com> TryBot-Result: Gobot Gobot <firstname.lastname@example.org> Reviewed-by: Bryan C. Mills <email@example.com>