The issue is the osDefaultInheritEnv initialization.

Notably even before CL 522318, changing the initialization from:

var osDefaultInheritEnv = func() []string { ... }()

to

var osDefaultInheritEnv []string

func init() { osDefaultInheritEnv = func() []string { ... }() }

causes the same linker failure.

Alternatively, changing the initialization to:

var osDefaultInheritEnv = getOSDefaultInheritEnv()

func getOSDefaultInheritEnv() []string { ... }

avoids the issue.

I think there's something weird about when closures are inlined into an init function. An effect of CL 522318 was basically to treat all package-scope initialization statements as though they were in an init statement, which is why the behavior is now the same as moving the assignment into an explicit func init() { ... } declaration.

@cuonglm Do you think this could be related to the IsDeadcodeClosure logic in inline/inl.go?

Change https://go.dev/cl/522935 mentions this issue: net/http/cgi: workaround for closure inlining issue

@cuonglm Do you think this could be related to the IsDeadcodeClosure logic in inline/inl.go?

It's very likely the culprit. Probably we need to visit typecheck.Target.Inits, too?

Probably we need to visit typecheck.Target.Inits, too?

I don't think so. The functions in Target.Inits are in Target.Funcs too. Target.Inits is only necessary so pkginit.MakeTask can list them all in the inittask. Otherwise, they should just be normal functions.

(Clearly there's some way that they're not behaving just like normal functions though.)

Probably we need to visit typecheck.Target.Inits, too?

I don't think so. The functions in Target.Inits are in Target.Funcs too. Target.Inits is only necessary so pkginit.MakeTask can list them all in the inittask. Otherwise, they should just be normal functions.

(Clearly there's some way that they're not behaving just like normal functions though.)

Hmm, that's right. Have my laptop now, will take a look.

@mdempsky So the problem is that after https://go-review.googlesource.com/c/go/+/492016, we need to mark hidden closures produced by inlining as un-hidden, but we're only marking closure which is converted to global during static init (That's why we see this behavior after CL 522318).

Seems that we need to mark any closures as un-hidden why processing init function?

Change https://go.dev/cl/522956 mentions this issue: cmd/compile: un-hide closure func in init function

Change https://go.dev/cl/523038 mentions this issue: Revert "net/http/cgi: workaround for closure inlining issue"

Change https://go.dev/cl/523037 mentions this issue: cmd/compile: retire "IsHiddenClosure" and "IsDeadcodeClosure"

Change https://go.dev/cl/523175 mentions this issue: Revert "net/http/cgi: workaround for closure inlining issue"