You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
059c1d68e2
When we use `go list` on the standard library, we need to be careful about what flags are passed from the top-level build command, because some flags are not going to be appropriate. In particular, GOFLAGS=-modfile=... resulted in a failure, reproduced via the GOFLAGS variable added to linker.txtar: go: inconsistent vendoring in /home/mvdan/tip/src: golang.org/x/crypto@v0.5.1-0.20230203195927-310bfa40f1e4: is marked as explicit in vendor/modules.txt, but not explicitly required in go.mod golang.org/x/net@v0.7.0: is marked as explicit in vendor/modules.txt, but not explicitly required in go.mod golang.org/x/sys@v0.5.1-0.20230208141308-4fee21c92339: is marked as explicit in vendor/modules.txt, but not explicitly required in go.mod golang.org/x/text@v0.7.1-0.20230207171107-30dadde3188b: is marked as explicit in vendor/modules.txt, but not explicitly required in go.mod To ignore the vendor directory, use -mod=readonly or -mod=mod. To sync the vendor directory, run: go mod vendor To work around this problem, reset the -mod and -modfile flags when calling "go list" on the standard library, as those are the only two flags which alter how we load the main module in a build. The code which builds a modified cmd/link has a similar problem; it already reset GOOS and GOARCH, but it could similarly run into problems if other env vars like GOFLAGS were set. To be on the safe side, we also disable GOENV and GOEXPERIMENT, which we borrow from Go's bootstrapping commands. |
3 years ago | |
|---|---|---|
| .. | ||
| asthelper | 4 years ago | |
| linker | 3 years ago | |
| literals | 3 years ago | |