cmd/go, cmd/link: support failure to create _cgo_import.go

For a package that uses cgo, the file _cgo_import.go is created to
record information required for internal linking: the non-Go dynamic
symbols and libraries that the package depends on. Generating this
information sometimes fails, because it can require recreating all the
dependencies of all transitively imported packages. And the
information is rarely needed, since by default we use external linking
when there are packages outside of the standard library that use cgo.

With this CL, if generating _cgo_import.go fails, we don't report an
error. Instead, we mark the package as requiring external linking, by
adding an empty file named "dynimportfail" into the generated archive.
If the linker sees a file with that name, it rejects an attempt to use
internal linking.

Fixes #52863

Change-Id: Ie586e6753a5b67e49bb14533cd7603d9defcf0ea
Reviewed-on: https://go-review.googlesource.com/c/go/+/413460
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This commit is contained in:
Ian Lance Taylor 2022-06-21 18:11:32 -07:00 committed by Gopher Robot
parent aca37d16a5
commit bdab4cf47a
5 changed files with 131 additions and 10 deletions

View file

@ -753,6 +753,16 @@ presented to cmd/link as part of a larger program, contains:
_go_.o # gc-compiled object for _cgo_gotypes.go, _cgo_import.go, *.cgo1.go
_all.o # gcc-compiled object for _cgo_export.c, *.cgo2.c
If there is an error generating the _cgo_import.go file, then, instead
of adding _cgo_import.go to the package, the go tool adds an empty
file named dynimportfail. The _cgo_import.go file is only needed when
using internal linking mode, which is not the default when linking
programs that use cgo (as described below). If the linker sees a file
named dynimportfail it reports an error if it has been told to use
internal linking mode. This approach is taken because generating
_cgo_import.go requires doing a full C link of the package, which can
fail for reasons that are irrelevant when using external linking mode.
The final program will be a dynamic executable, so that cmd/link can avoid
needing to process arbitrary .o files. It only needs to process the .o
files generated from C files that cgo writes, and those are much more