Re: go package build problem: go: cannot find GOROOT directory: 'go' binary is trimmed and GOROOT is not set

[Benny Siegert <bsiegert%gmail.com@localhost>]

I can confirm that this occurs when /proc is not mounted, and it does
not occur when /proc is mounted.

in src/os/executable_procfs.go, Go uses /proc on NetBSD and Linux to
determine the path to the go tool. On FreeBSD, for comparison, it runs
"sysctl proc.pathname", which NetBSD does not have.

As far as I can tell, it takes the path for the "go" tool (e.g.
/usr/pkg/bin/go"), follows symlinks to come up at
/usr/pkg/go121/bin/go121 and concludes that /usr/pkg/go121 is the
correct GOROOT -- but only if it can determine the executable path,
i.e. with /proc mounted. That logic is here:
https://cs.opensource.google/go/go/+/master:src/cmd/go/internal/cfg/cfg.go;l=473;bpv=1;bpt=0

Now, why does it do this dance in the first place? Previously, the
value passed in as GOROOT_FINAL was hard-coded as a default value into
the compiled standard library. The build indicates that this should
still be the case, as it ends with a message like

The binaries expect /usr/obj/pkgsrc/lang/go121/work/go to be copied or
moved to /usr/pkg/go121

Inspecting the actual "go" binary with strings shows that the older
versions, up to and including 120, have the goroot in the binary while
121 does not. I assume something in the build turns on the "-trimpath"
option to remove that. There were some toolchain changes around
portability of binaries, so that could be related.

-- 
Benny