https://pantsbuild.org/ logo
Join Slack
Powered by
Do we have any Go pros in here? I'm hacking a bit ...
# development
g
Do we have any Go pros in here? I'm hacking a bit on a Pants-hosted Go compiler, but something is broken and I don't quite understand what. Some tests are starting to work, but a lot are failing on the following compilation issue:
Copy code
E       Exception: Failed to compile main:
E       open .go-1.21.6/src/internal/goarch/goarch.go: no such file or directory
With the command
Copy code
E       + exec .go-1.21.6/bin/go tool compile -buildid a717bf895dab0e5694d00390aa961411b8035d984aa5650934a87c42e83a3dcc -o __pkg__.a -pack -p internal/goarch -importcfg ./importcfg -lang go1.21 -std -+ -complete @__sources__.txt
I've never seen this error before, and the internet contains no traces of this specific issue either. The files definitely exist in the sandbox (🧵), and the go environment looks kosher. Anyone got any ideas or leads? 🙂
Some random debug output I've added:
Copy code
E       + which go
E       .go-1.21.6/bin/go
E       + echo 'GOROOT: .go-1.21.6'
E       GOROOT: .go-1.21.6
E       + echo 'GOPATH: gopath'
E       GOPATH: gopath
E       + echo 'GOCACHE: cache'
E       GOCACHE: cache
E       + cat __sources__.txt
E       .go-1.21.6/src/internal/goarch/goarch.go
E       .go-1.21.6/src/internal/goarch/goarch_amd64.go
E       .go-1.21.6/src/internal/goarch/zgoarch_amd64.go
E       + go env --json
E       {
E               "AR": "ar",
E               "CC": "gcc",
E               "CGO_CFLAGS": "-O2 -g",
E               "CGO_CPPFLAGS": "",
E               "CGO_CXXFLAGS": "-O2 -g",
E               "CGO_ENABLED": "1",
E               "CGO_FFLAGS": "-O2 -g",
E               "CGO_LDFLAGS": "-O2 -g",
E               "CXX": "g++",
E               "GCCGO": "gccgo",
E               "GO111MODULE": "",
E               "GOAMD64": "v1",
E               "GOARCH": "amd64",
E               "GOBIN": "",
E               "GOCACHE": "cache",
E               "GOENV": "",
E               "GOEXE": "",
E               "GOEXPERIMENT": "nocoverageredesign",
E               "GOFLAGS": "",
E               "GOGCCFLAGS": "-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build3969111599=/tmp/go-build -gno-record-gcc-switches",
E               "GOHOSTARCH": "amd64",
E               "GOHOSTOS": "linux",
E               "GOINSECURE": "",
E               "GOMOD": "/dev/null",
E               "GOMODCACHE": "gopath/pkg/mod",
E               "GONOPROXY": "",
E               "GONOSUMDB": "",
E               "GOOS": "linux",
E               "GOPATH": "gopath",
E               "GOPRIVATE": "",
E               "GOPROXY": "off",
E               "GOROOT": ".go-1.21.6",
E               "GOSUMDB": "sum.golang.org",
E               "GOTMPDIR": "",
E               "GOTOOLCHAIN": "auto",
E               "GOTOOLDIR": ".go-1.21.6/pkg/tool/linux_amd64",
E               "GOVCS": "",
E               "GOVERSION": "go1.21.6",
E               "GOWORK": "",
E               "PKG_CONFIG": "pkg-config"
E       }
E       + ls -al .go-1.21.6/src/internal/goarch/
E       total 164
E       drwxr-xr-x  2 ts ts 4096 Jan 29 22:31 .
E       drwxr-xr-x 47 ts ts 4096 Jan 29 22:31 ..
E       -rw-r--r--  1 ts ts 1517 Jan 29 22:31 gengoarch.go
E       -rw-r--r--  1 ts ts 2157 Jan 29 22:31 goarch.go
          <snip rest of files>
f
I believe GOROOT has to be an absolute path.
Imagine if the current directory is changed.
g
That's the weird part. I am setting it to be absolute. I've tried different different methods. Check my thread in #random. Something is misbehaving a ton with my pants-sandboxes. I assumed it was just a display issue in Pants, but maybe it's actually a bug/issue somewhere. Fwiw, all three dirs (path/root/cache) are
Copy code
sandbox_root="$(/bin/pwd)"
GOROOT=${{sandbox_root}}/{goroot.path}
GOPATH=${{sandbox_root}}/gopath
GOCACHE=${{sandbox_root}}/cache
And all of them look like relative paths, even in 
go env
But that sandbox_root variable behaves like it's empty when it's joined with anything else. On its own, works fine.
It was a path issue, but not what the logs showed. The 
__SOURCES__
file contain(ed) absolute paths, so they pointed into another GOROOT. Now to fix the 10x slowdown caused by this... 😞
(Sigh, this is mentioned here already: https://docs.google.com/document/d/1e4djdm2D9L6IeeJ8Q1M0_yJU-kF4tTHopBomwzdDRpE/edit#heading=h.n4lrkjmz3x2s... But it does tell me that immutable caches should work with remote caches, which I wasn't sure of.)
3 Views
Open in Slack
PreviousNext
Powered by