x/tools: tests fail with gccgo

[TheTincho]

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

go version go1.6.1 gccgo (Debian 6.2.0-13) 6.2.0 20161109

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

Debian, all architectures not directly supported by the official compiler.

Hi, I am one of the people maintaining go libraries in Debian, and I have been trying to get x/tools to work with gccgo with no luck. We aim to provide golang support in all of our architectures, and so we use gccgo in mips*, alpha, powerpc, and now s390x.

We are able to build x/tools, but the tests fail spectacularly. I wonder if we are doing something very wrong, or is it that nobody ever tried to make it work there. Many errors seem to be related to tools expecting source code to be present for the stdlib, for example.

I would really appreciate if somebody could take a look at this, we are getting close to the freeze (before Debian stable is released), and I would like to fix that in time. The log from a sample build in mipsel is attached:

golang-golang-x-tools_0.0~git20161028.0.b814a3b+ds-3_mipsel.build.txt

[bradfitz]

Skimming quickly, it looks like everything compiles but some tests fail, all due to the same bug, locating source code.

/cc @ianlancetaylor @alandonovan

[bradfitz]

Related to: #11811 for Go 1.8.

[alandonovan]

The short answer is that nobody ever tried to make it work. As Brad said, most of the tests are failing because GOROOT appears to be set to /usr (not sure why). Once you fix that, I imagine the remaining problems are easily solved; please share the updated list. I just fixed one minor incompatibility in https://go-review.googlesource.com/33573.

[TheTincho]

@alandonovan , I don't know the reasons for the GOROOT setting (except that $GOROOT/bin makes sense in this context), but the problem is not that, but that the tools are looking for source files, when those are not available in a gccgo environment. All the stdlib is present as gox files in /usr/lib/mips64el-linux-gnuabi64/go/6/crypto.

In fact, if I run strace on one of the failing tests, I see that for reaching (for example) crypto/x509, only these are the relevant checks:

[pid 20493] stat("/usr/src/crypto/x509", 0xffe6be9570) = -1 ENOENT (No such file or directory)
[pid 20493] stat("/home/tincho/golang-golang-x-tools-0.0~git20161028.0.b814a3b+ds/build/src/crypto/x509", 0xffe6be9570) = -1 ENOENT (No such file or directory)

testdata/expr_type_mismatch.template:4:2: could not import crypto/x509 (cannot find package "crypto/x509" in any of:
	/usr/src/crypto/x509 (from $GOROOT)
	/home/tincho/golang-golang-x-tools-0.0~git20161028.0.b814a3b+ds/build/src/crypto/x509 (from $GOPATH))

So, no matter what the GOROOT is, it will still not work.

[ianlancetaylor]

@alandonovan GOROOT is meaningless for gccgo. Any test that relies on reading files out of GOROOT will fail when using gccgo.

[alandonovan]

@iant So how does the TestDeps test in the standard go/build package work under gccgo? It enumerates all packages beneath build.Default.GOROOT + "/src".

[ianlancetaylor]

The TestDependencies test in go/build passes easily. It gets a list of standard packages, which for gccgo is empty. Then it walks through that list and verifies that the dependencies for each package are correct. Since the list is empty, the test passes.

[alandonovan]

@TheTincho The only way tools from x/tools (or applications that use the standard go/build package) are going to work when built with gccgo is if, during installation, you have created a GOROOT directory and unpacked the sources for gccgo's standard library (found at svn://gcc.gnu.org/svn/gcc/branches/gccgo / libgo/go) into $GOROOT/src.

I have been struggling to use gccgo to verify whether even this is sufficient, and in any case build.golang.org does not run tests for x/tools using gccgo, so I am not filled with confidence. I'm afraid these tools are not going to work under gccgo before your deadline.

[TheTincho]

@alandonovan Thanks for looking into this. I understand this is not tested and adding the go sources just for this does not make sense.

In any case, I would like to be able to provide the subset of x/tools that can work with gccgo, but I don't know which tests fail because the library can't work there, or just because the tests are requiring source code. Are you saying that all of it requires the sources for the stdlib?

[alandonovan]

You should be able to use the following packages beneath golang.org/x/tools/cmd:
benchcmp cover goimports goyacc present stress stringer toolstash