I'd previously said that this happened with 1.6 but it doesn't, this is a regression (sadface).

Ah so the good news is that this is because the test is a bit silly (in a way that it is not in 1.6). And this is the real 'problem':

$ cat numgoroutine.go
package main

import "runtime"

func main() {
    println(runtime.NumGoroutine())
}
$ go run numgoroutine.go 
1
$ go run -linkshared numgoroutine.go 
2

This difference is present in 1.6 so not a regression. I'll either try to figure out what's going on or just fix the test in early 1.8.

@mwhudson Do we need to skip the test in 1.7?

It's not run by default, so I'd say no.

@mwhudson, I probably just don't know what I'm doing here, but when I tried to reproduce this I get:

$ go run -linkshared main.go
# command-line-arguments
/home/austin/go.dev/pkg/tool/linux_amd64/link: cannot implicitly include runtime/cgo in a shared library

I tried go install -linkshared runtime first, but it didn't help.

@aclements you need to run go install -buildmode=shared std first

Although the -linshared is probably irrelevant, it happens just when linking externally:

$ go run -ldflags='-linkmode=external' numgoroutine.go
2

Thanks.

It looks like the "second" goroutine is the spare M used by cgo callbacks. So this will appear whenever cgo is used.

Perhaps that should be marked as a system goroutine until it's actually used...

CL https://golang.org/cl/45030 mentions this issue.