cmd/go: consider path to the C and C++ compiler executable when deciding when to recompile CGO packages

[Keithcat1]

I have 2 versions of GCC on my computer, but it seems that Go can't tell the difference. It would be good if Go remembered the path to the compiler executables and recompile if it changed to avoide incompatibilities.

[ianlancetaylor]

Can you show us a short example? I can think of a few different things you might mean, and I want to be sure that we understand the actual problem that you are encountering. Thanks.

[Keithcat1]

I`ve had some problems when the linker from GCC10.1.0 tried to link artifacts compiled by GCC9.2, specifically when doing link-time-optimization as the different compilers can't read the others LTO representation.
This is probably not the only problem that you could encounter. You could accidentally compile with GCC10.1, then link with an earlier version that doesn't define a symbol that the later version has.
I emagine that remembering the path to the compiler executable would fix this problem.

[jayconrod]

@Keithcat1 Could you please add:

• Complete output of go env for both compiler versions used.
• Method you're using to switch compilers? Are you setting CC? PATH? Something else?
• CGO_CFLAGS, CGO_LDFLAGS and similar, either set on the command line or with #cgo directives.
• Short example program.
• Sequence of commands run and error messages seen in output.

The go command does store some information about the C compiler used, but it may not be enough to detect all changes. Without knowing more about your situation, it's hard to say if there's a bug here, so please add more detail.

[Keithcat1]

Hi,
The method of switching compilers I am using is to change the path.
Both compilers are gcc.exe.
I am not using any CGO environment variables.
The only notable #cgo CFLAGS and CXXFLAGS I have set are:
#cgo CFLAGS: -I${SRCDIR}/include -DWITH_MINIAUDIO -Wno-multichar -Wno-unused-value -msse
#cgo CXXFLAGS: -I${SRCDIR}/include -DWITH_MINIAUDIO -Wno-multichar -Wno-macro-redefined -Wno-unused-value -msse
#cgo CXXFLAGS: -flto
#cgo windows LDFLAGS: -static
Go env for GCC 9.2.0:

[ianlancetaylor]

I think the current mechanism is to use the value of the environment variable CC, which defaults to the value of CC used when the Go tool were built, which defaults to gcc. So if you are getting different compilers strictly by changing PATH, then I think you will indeed get the same build ID for both. If you change CC instead, you will get different build IDs.

I guess the question for the go tool is whether it should call os/exec.LookPath to fetch the full path when computing the build ID.

[jayconrod]

We may want to invoke the C compiler to incorporate some version information, too. We do something that for the Go compiler and other tools.

[ianlancetaylor]

Sure, you can get real information about the C compiler by using (*Builder).gccgoToolID.

[Keithcat1]

Maybe just make an SHA256 hash of the C compiler and recompile if it changes?

[ianlancetaylor]

The C compiler is a collection of different programs, so computing a hash is not trivial. The gccgoToolID method that I mentioned already does what I think is the right thing. See https://golang.org/src/cmd/go/internal/work/buildid.go?#L217 .

[gopherbot]

Change https://golang.org/cl/314276 mentions this issue: cmd/go: include C/C++/Fortran compiler version in build ID

[gopherbot]

Change https://golang.org/cl/335409 mentions this issue: cmd/go: don't add C compiler ID to hash for standard library