Comment 1:

Labels changed: added priority-go1, gccgo, removed priority-triage.

Comment 2:

It is true: the go tool does not do anything with buildGccgoflags.
That's easy to fix.
I am more concerned by your report of running 6g and 6l during
this.  What were the command lines?  Did gccgo get invoked
for anything at all?

Comment 3:

I take it back about buildGccgoflags.  They do get used.
I missed them in the grep output.

Comment 4:

Not quite sure if you're saying that there's a bug or not.
Still with 4346881f5c9d tip:
GOROOT= GOPATH=~/myproj strace -f -s1000 -ostrace.log go test -compiler=gccgo
-gccgoflags='--coverage' -c -work somepkg
src/somepkg/x.go:7:2: import "bytes": cannot find package
src/somepkg/x.go:8:2: import "crypto/rand": cannot find package
src/somepkg/x.go:9:2: import "fmt": cannot find package
package somepkg
        imports runtime: import "runtime": cannot find package
src/somepkg/x.go:10:2: import "syscall": cannot find package
So bug #1 is that gccgo doesn't work when GOROOT is empty. I'm under the impression that
it should.
Let's leave GOROOT as is.
Then I get:
WORK=/dev/shm/go-build309986423
warning: building out-of-date packages:
        runtime
        errors
        sync/atomic
        sync
        io
        unicode
        unicode/utf8
        bytes
        bufio
        crypto/cipher
        math
        strconv
        crypto/aes
        reflect
        encoding/binary
        syscall
        time
        os
        fmt
        math/rand
        strings
        math/big
        crypto/rand
        sort
        flag
        text/tabwriter
        runtime/pprof
        testing
        regexp/syntax
        regexp
installing these packages with 'go test -i somepkg' will speed future tests.
As far as I can tell from the strace log at this point, gccgo is never executed.

Comment 5:

Regarding the GOROOT issue:
What is your GOROOT set to?
Is the go command compiled by 6g or by gccgo?
Do you use the same GOROOT for both?
Did you compile the go command with that goroot?
What does go tool dist env print?

Comment 6:

GOROOT is set to $HOME/go
go command is compiled by 6g.
I'm trying to use the same GOROOT for both 6g and gccgo builds.
gccgo is installed under /opt/gccgo. /opt/gccgo/bin is in my path. I guess technically
gccgo's GOROOT is /opt/gccgo?
$ go tool dist env
GOROOT="/home/alberts/go"
GOBIN="/home/alberts/go/bin"
GOARCH="amd64"
GOOS="linux"
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOTOOLDIR="/home/alberts/go/pkg/tool/linux_amd64"
GOCHAR="6"
CGO_ENABLED="1"
I think something fun is happening here, which might also be an issue for the binary
distros.
There are two ways that I obtain my GOROOT contents on this machine.
1. cd ~/go/src && ./make.bash
2. cd ~ && rm -rf go && wget
http://buildmachine/job/go/lastSuccessfulBuild/artifact/go.tar.gz && tar -zxvf go.tar.gz
If I do number 1, I always get the "6g/6l builds instead of gccgo" behaviour described
above, regardless of whether GOROOT is empty or not.
If I do number 2, I get the "6g/6l builds instead of gccgo" behaviour if GOROOT is set
to $HOME/go and the "imports cannot be found" behaviour if GOROOT is empty, probably
because the go command thinks that my GOROOT is /var/lib/jenkins/jobs/go/workspace/go in
this case.
I haven't looked at setting GOROOT_FINAL on the build machine because everyone here
installs these builds in their $HOME/go and set GOROOT accordingly.

Comment 7:

It might help to understand issue #3228 too.

Comment 8:

I am not worried about the GOROOT stuff.
If you are running a 6g-compile go command
then it will be looking in $HOME/go/pkg for
package archives and $HOME/go/src/pkg for
package sources.  If your gccgo is in /opt/gccgo,
then that's not going to work.
Setting GOROOT= doesn't work because, as you
surmised, the default is wrong in the go binary
you are invoking.
I see now why go test invokes 6g instead of gccgo.
Will fix.

Comment 9:

This issue was closed by revision 807aadc.

Status changed to Fixed.

Comment 10:

I'm still not clear on a few things:
1. Can 6g-compiled go be used to build with gccgo?
2. If 1, what should I set GOROOT to, to work with gccgo?
If not 1, what is the procedure for building a gccgo "native" go tool?

Comment 11:

Yes (at least after my bug fix).
You need to set it to the tree where the gccgo binaries are,
which sounds like /opt/gccgo on your system.
You could use the 6g go tool to build a gccgo go tool.  :-)