Here is a patch to fix this. It seems that build.ToolDir was not being pulled in for some reason.

diff --git a/src/cmd/go/tool.go b/src/cmd/go/tool.go
index 29feb1d..44744fa 100644
--- a/src/cmd/go/tool.go
+++ b/src/cmd/go/tool.go
@@ -6,7 +6,7 @@ package main

 import (
        "fmt"
-       "go/build"
+//     "go/build"
        "os"
        "os/exec"
        "path/filepath"
@@ -34,7 +34,7 @@ var (
        toolGOOS      = runtime.GOOS
        toolGOARCH    = runtime.GOARCH
        toolIsWindows = toolGOOS == "windows"
-       toolDir       = build.ToolDir
+       toolDir       = filepath.Join(runtime.GOROOT(), "pkg/tool/"+runtime.GOOS+"_"+runtime.GOARCH)

        toolN bool
 )

diff --git a/src/go/build/build.go b/src/go/build/build.go
index b590105..d1be497 100644
--- a/src/go/build/build.go
+++ b/src/go/build/build.go
@@ -1377,7 +1377,7 @@ func init() {
 }

 // ToolDir is the directory containing build tools.
-var ToolDir = filepath.Join(runtime.GOROOT(), "pkg/tool/"+runtime.GOOS+"_"+runtime.GOARCH)
+//var ToolDir = filepath.Join(runtime.GOROOT(), "pkg/tool/"+runtime.GOOS+"_"+runtime.GOARCH)

 // IsLocalImport reports whether the import path is
 // a local import path, like ".", "..", "./foo", or "../foo".

part of #10092

The proposed change seems clearly wrong for gccgo in general. If I apply that patch, the gccgo version of the go tool will no longer be able to invoke the cgo tool.

Ok, I do not understand why the build.ToolDir is not getting set from that expression and where it is coming from instead, how it is getting the /usr/local value. This is just the workaround that I put in place to continue working on it. Have not tried with cgo.

For gccgo, build.Tooldir is set based on a value computed in libgo/Makefile.am. See the s-version target in that file for the original source.

The important point is that the gccgo-built version of the go tool must be able to locate the gccgo-built version of the cgo tool.

OK, that explains the behavior. But If we are to recompile that in a bootstrap we will want to be able to override it in the env.

I am working on compiling the entire go core with gccgo and not with gc itself. This is an experiment to make gccgo a better implementation of go.

The use case for this patch is for example where to find the cgo command, I want to compile the cgo from the go source not use one compiled by gccgo for example. Basically I would like this to be flexible and not hard coded to one path.

Hi there, these are good points, will have to think about that. Right now this is my GO learning project and I intend to continue working on it as i have time. I have been working on patches to the build.go to emit Makefiles and I hope to find other interesting usages of the core code. If I find a roadblock that requires gc of course I can use it for that specific case or rewrite the code. Once I have had my learning time I will be able to make better contributions. I would really like to learn more about how to improve the gcc, and I hope I will be able to do that.

I feel like I'm not grasping the point of this.

I originally thought that you wanted to be able to use gccgo as a bootstrap compiler to start a gc build. That sounds useful. But now it sounds like you want to compile the gc cmd/go code with the gccgo go/build package. That isn't going to work, and making that work doesn't seem like a useful exercise. If that is a necessary step for using gccgo as the bootstrap compiler for a gc build, then can you walk through the high-level steps that get us to that point? Thanks.

if you have gccgo installed into a system dir and want to have it call out to user tools you will need this feature. Lets say a user has a custom goc binary that they compiled using whatever means, we should support overriding the hardcoded location of the binaries, just for the flexibility of the user.

Makes sense, I suppose. We would have to figure out a good approach. Setting GOTOOLDIR in the environment does not affect the standard go tool at all. Setting GOROOT, GOARCH, and GOOS does affect it. For GCC, on the other hand, setting GCC_EXEC_PREFIX affects where it finds the tools. I don't know what is best.

Hello,
as a user I would like to be able to influence the binaries used. Compiling gccgo is a major undertaking and consumes large amounts of resources. A hard coded path is useful as a fall back but I would like to be able to run the commands out of the build directory without installing them as well. A little bit of flexibility is surely welcomed. I appreciate the way that the go system all works together and that Is a great feature, and it should work that way by default but some users are going to want to influence the way it runs.

I agree that we should first focus on the steps needed to compile the go compiler and then bootstrap via that gc. Afterwards I can look into compiling other code to look for compiler bugs.

GOTOOLDIR is printed by go env for use by things that want to get to the tool dir. It is explicitly NOT something that is pulled from the environment. This is working as intended.

(Note that similarly even though go env prints GOCHAR= you cannot override GOCHAR.)