cmd/compile: "go tool compile foo.go " doesn't work

[erifan]

What version of Go are you using (go version)?

$ go version
go version devel go1.20-fee0ab8b5e Thu Nov 17 03:47:35 2022 +0000 darwin/arm64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
darwin/arm64

What did you do?

$ cat foo.go
package main

import (
"fmt"
)

func main() {
fmt.Println("he")
}

$ go tool compile foo.go

What did you expect to see?

The program compiles.

What did you see instead?

foo.go:4:2: could not import fmt (file not found)

Git bisect points to https://go-review.googlesource.com/c/go/+/432535 cc @michaelmatloob

[cuiweixie]

weixiecui@weixiecui-pc0 MINGW64 /d/code/go/src/go (master)
$ go tool compile foo.go
foo.go:4:2: could not import fmt (file not found)

weixiecui@weixiecui-pc0 MINGW64 /d/code/go/src/go (master)
$ go build -o ./pkg/windows_amd64/fmt.a fmt

weixiecui@weixiecui-pc0 MINGW64 /d/code/go/src/go (master)
$ go tool compile foo.go

maybe just need to compile the fmt package to goroot or gopath.

[ianlancetaylor]

You can also set GODEBUG=installgoroot=all in the environment and run go install fmt.

In general go tool compile is not expected to always work by itself. go build is supported, go tool compile is not.

[erifan]

For go1.19, go1.18 and previous versions of go, this usage is feasible, the latest code before CL 432535 also supports this usage, and I didn't see any discussion of changing this behavior in #47257. In my opinion, this is a common user behavior change, does not it require a proposal process? @rsc

"go tool compile" is very useful, especially "go tool compile -S", because you don't need to go through "go build" + "go tool objdump" to check the generated assembly code.

Temporarily reopen this issue, I'll close it if this is still not considered an issue.

[randall77]

I often get tripped up on this when compiling a test for other architectures, where the test imports a package like fmt that has not been compiled yet for that architecture. This is a problem even with 1.19 and earlier - we'd have to include .a files for all os/arch combinations to really fix it. I don't see any way go tool compile -S can solve this problem. I end up doing go build -gcflags=-S or equivalent and then look through the (sometimes large) output for the disassembly I want.

[ianlancetaylor]

You can go build -gcflags=MYPKG=-S to pass the -S option only when compiling the package you are interested in.

[erifan]

Thanks @randall77 @ianlancetaylor go build -gcflags=MYPKG=-S can basically replace go tool compile -S. But there is another case that ordinary developers may not use so often, that is, sometimes I need to check the information in the .o file, such as the relocation types, especially when doing linker-related work. I tried go build -gcflags="-o XXX.o" but it doesn't work. And go build doesn't seem to have an option to stop the build process just after compilation?

In fact, I think whether go tool compile simple_program.go can work is the same as whether go build simple_program.go can work without the .mod file. My personal opinion is that if simple_program.go only imports standard libraries, it should be able to work, that is, the compiler should be able to find the location of the standard library. This can bring great convenience to debugging simple programs, and the compiler tool should not be designed to be used only by go build.

[ianlancetaylor]

If you run GODEBUG=installgoroot=all go install std then you should be able to run go tool compile for code that just imports the standard library.

Closing because this is a workflow that we've decided, for what we think are good reasons, to not support by default.

[erifan]

for what we think are good reasons

Okay, can you elaborate ? Or point me to the issue link. Is it #47257 ?