Issue title: static linking a no-op binary fails
 Issue body: ### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.17 linux/amd64
</pre>
Note I was using the docker `golang:1.17-buster` image.
### Does this issue reproduce with the latest release?
yes, it reproduces with the latest go 1.17


### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/root/.cache/go-build"
GOENV="/root/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.17"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build838287027=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?

I tried to statically compile a simple main file:
```
$ cat go.mod
module naphatkrit/go-bug-repro

go 1.17
$ cat main.go
package main

func main() {
}
```

I then ran `go build` with the flags needed to statically link my binary, this results in a warning about not being able to find cgo.
```
$ go build -a -v -o /tmp/my-binary -ldflags "-linkmode external -extldflags -static" -trimpath .
runtime/internal/sys
internal/goexperiment
internal/cpu
internal/abi
runtime/internal/atomic
runtime/internal/math
internal/bytealg
runtime
naphatkrit/go-bug-repro
# naphatkrit/go-bug-repro
loadinternal: cannot find runtime/cgo
```

### What did you expect to see?

When I execute the binary, I expect the binary to run and exit.

### What did you see instead?
Executing the binary results in a trap error
```
$ /tmp/my-binary
Trace/breakpoint trap
```

Additionally, here is what strace shows:
```
root@3f441e3ed41c:/code# strace /tmp/my-binary
execve("/tmp/my-binary", ["/tmp/my-binary"], 0x7fff5db80d00 /* 10 vars */) = 0
brk(NULL)                               = 0xf03000
brk(0xf041c0)                           = 0xf041c0
arch_prctl(ARCH_SET_FS, 0xf03880)       = 0
uname({sysname="Linux", nodename="3f441e3ed41c", ...}) = 0
readlink("/proc/self/exe", "/tmp/my-binary", 4096) = 14
brk(0xf251c0)                           = 0xf251c0
brk(0xf26000)                           = 0xf26000
arch_prctl(ARCH_SET_FS, 0x55fd90)       = 0
--- SIGTRAP {si_signo=SIGTRAP, si_code=SI_KERNEL} ---
+++ killed by SIGTRAP +++
Trace/breakpoint trap
```

If I forcibly include runtime/cgo, the build warning goes away and the compiled binary runs fine.
```
$ cat main.go
package main

import _ "runtime/cgo"

func main() {
}
```

```
$ go build -a -v -o /tmp/my-binary -ldflags "-linkmode external -extldflags -static" -trimpath .
internal/race
runtime/internal/sys
internal/abi
internal/cpu
internal/goexperiment
runtime/internal/atomic
sync/atomic
runtime/internal/math
internal/bytealg
runtime
sync
runtime/cgo
naphatkrit/go-bug-repro
$ /tmp/my-binary
$
```
Am I doing static linking wrong?

I have put up my repro at https://github.com/naphatkrit/go-bug-repro for convenience
 Comments: 
 Comment 0: Unlike many projects, the Go project does not use GitHub Issues for general discussion or asking questions. GitHub Issues are used for tracking bugs and proposals only.

For questions please refer to https://github.com/golang/go/wiki/Questions
 Comment 1: This looks like a go bug doesn’t it?
 Comment 2: Why the complicated recipe? Go builds static binaries by default. Just `go build` should work.

 Comment 3: wait is that true even when there are dependencies? when I tried to build a more complicated example from work and run it through ldd, it's clearly not statically linked when only using `go build`:
```
$ ldd <my binary>
	linux-vdso.so.1 (0x00007ffc13bfe000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f87cd2ed000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f87cd12c000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f87cd314000)
```
 Comment 4: When you're using cgo, all bets are off, as the C code can pull in dynamic dependencies. But if you're using cgo your recipe works.
I think there's some issues with some packages (net?) that pull in dynamically linked libraries. Not sure though, that may just be OSX.

 Comment 5: did a little more tingling, it seems the culprit is `-linkmode external`. Without it, the produced binary is static and doesn't have the issue described here (according to `ldd` and `file`). I have tried this with code that imports only stdlib cgo packages like `net` and `os` only (while passing `-tags 'osusergo,netgo'`), and also with code that imports custom cgo packages like sqlite. 

It does feel like it works accidentally though. Reading the doc for linkmode, 
> By default, cmd/link will decide the linking mode as follows: if the only packages using cgo are those on a list of known standard library packages (net, os/user, runtime/cgo), cmd/link will use internal linking mode. Otherwise, there are non-standard cgo packages involved, and cmd/link will use external linking mode.

So without custom cgo code, the internal linker does the right thing. With custom cgo code like sqlite, the external linker is pulled in but the custom code also pulls in runtime/cgo, so that also ensures the issue I described doesn't show up. It appears the problem is when combining external linker with stdlib cgo code and `-tags 'osusergo,netgo'`, which then causes it to compile a binary with runtime/cgo and andrew77@example.net.
{'source': 'GithubIssues', 'repo_name_with_owner': 'golang/go', 'issue_id': 983149292, 'repo_stars': 113207.0}