Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
Keithcat1 opened this issue Jul 4, 2020 · 9 comments
Milestone

Comments

@Keithcat1
Copy link

@Keithcat1 Keithcat1 commented Jul 4, 2020

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 ianlancetaylor changed the title CGO: Consider path to the C and C++ compiler executable when deciding when to recompile CGO packages cmd/go: consider path to the C and C++ compiler executable when deciding when to recompile CGO packages Jul 4, 2020
@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Jul 4, 2020

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
Copy link
Author

@Keithcat1 Keithcat1 commented Jul 5, 2020

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
Copy link
Contributor

@jayconrod jayconrod commented Jul 6, 2020

@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
Copy link
Author

@Keithcat1 Keithcat1 commented Jul 8, 2020

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
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Jul 8, 2020

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.

@ianlancetaylor ianlancetaylor added this to the Backlog milestone Jul 8, 2020
@jayconrod
Copy link
Contributor

@jayconrod jayconrod commented Jul 8, 2020

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
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Jul 8, 2020

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

@Keithcat1
Copy link
Author

@Keithcat1 Keithcat1 commented Jul 8, 2020

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

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Jul 9, 2020

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 .

@jayconrod jayconrod modified the milestones: Backlog, Go1.16 Jul 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.