Setting GOPATH within GOROOT is definitely not a supported configuration, but maybe we should generate a better error for it.

/cc @jayconrod

A GOROOT of /opt/freeware seems like a problem in general. GOROOT has a lot of really generic directories such as src, test, and misc that are likely to conflict with other programs.

In particular, if we were to add a packages package to the standard library, then a GOROOT of /opt/freeware would place that package's source at /opt/freeware/src/packages.

At any rate, we do have a similar existing diagnostic, if someone wants to expand it using search.InDir:

GOROOT is set to /opt/freeware only with gccgo. And I think this is because we are using --prefix="/opt/freeware" when building gcc in general.
Maybe @ianlancetaylor, you're aware of such problems in a different OS ?
Edit: I do confirm with this is linked with `--prefix`` and comes from https://github.com/golang/gofrontend/blob/master/libgo/Makefile.am#L556. Maybe it can be adapted for AIX.

The gccgo default for GOROOT is definitely problematic. See https://gcc.gnu.org/PR89171. I've been intending to take a look at it before the next GCC release.

Change https://golang.org/cl/185540 mentions this issue: cmd/go: Warn when GOPATH is a subdir of GOROOT

I am unable to reproduce the issue. The only way I can convince go to not find something under GOPATH is to reference it incorrectly. Even when GOPATH is a sub-directory of GOROOT. Can you post the code or at least the import block @Helflym ?

You're right, my error occurs only because GOPATH is a sub-directory of $GOROOT/src (and not simply $GOROOT). It's very unlikely that it'll ever occur with Golang as GOROOT as a true meaning. However, with the current gccgo, GOROOT is more a placeholder AFAIK.

$ go env 
GOROOT="/tmp/go-root"
GOPATH="/tmp/go-root/src/go-path"
$ cd /tmp/go-root/src/go-path/src/golang.org/x/sys/unix 
$ GO111MODULE=off go build
can't load package: package go-path/src/golang.org/x/sys/unix: code in directory /tmp/go-root/src/go-path/src/golang.org/x/sys/unix expects import "golang.org/x/sys/unix"

GO111MODULE=off is just to make a more explicit error.

@Helflym I still have not be able to reproduce this. Can you at least post the import block of your main go file? I have tried all the combinations I can think of as far as file and import structure to cause this, but I get no errors.

qbradq@qbradq-AB350-Gaming:~/golang/src/go-path/src/golang.org/x/sys/unix$ set | grep GO
GOPATH=/home/qbradq/golang/src/go-path
GOROOT=/home/qbradq/golang
qbradq@qbradq-AB350-Gaming:~/golang/src/go-path/src/golang.org/x/sys/unix$ cat main.go
package main

import "golang.org/x/sys/unix/sub"

func main() {
	sub.SayHello()
}
qbradq@qbradq-AB350-Gaming:~/golang/src/go-path/src/golang.org/x/sys/unix$ cat sub/lib.go
package sub

import "fmt"

// SayHello says hello
func SayHello() {
	fmt.Println("Hello, #32621!")
}
qbradq@qbradq-AB350-Gaming:~/golang/src/go-path/src/golang.org/x/sys/unix$ GO111MODULE=off $GOROOT/bin/go build
qbradq@qbradq-AB350-Gaming:~/golang/src/go-path/src/golang.org/x/sys/unix$ ./unix
Hello, #32621!

I was using the whole x/sys/unix package (https://github.com/golang/sys) not a simple main.go and its sub package.
But indeed, it does work with your simple example. It could be interesting to know why it does with this simple package but it doesn't with a complex package like x/sys/unix.
Anyway, here is the imports of x/sys/unix,

$ go list -f '{{ .Imports }}'
[bytes encoding/binary net runtime sort strings sync syscall time unsafe]

@Helflym Thank you the patience :) I understand now that you are trying to build the golang.org/x/sys/unix package. I was able to reproduce the issue when building this package. I am continuing analysis now.

To reproduce:

$ mkdir /tmp/issue-32621
$ cd /tmp/issue-32621
$ export GOROOT=$(pwd)
$ export GOPATH=$GOROOT/src/gopath
$ mkdir -p $GOPATH
$ go get golang.org/x/sys/unix
package bytes: unrecognized import path "bytes" (import path does not begin with hostname)
package encoding/binary: unrecognized import path "encoding/binary" (import path does not begin with hostname)
package runtime: unrecognized import path "runtime" (import path does not begin with hostname)
package sort: unrecognized import path "sort" (import path does not begin with hostname)
package strings: unrecognized import path "strings" (import path does not begin with hostname)
package sync: unrecognized import path "sync" (import path does not begin with hostname)
package syscall: unrecognized import path "syscall" (import path does not begin with hostname)
package time: unrecognized import path "time" (import path does not begin with hostname)
package unsafe: unrecognized import path "unsafe" (import path does not begin with hostname)
$ cd src/gopath/src/golang.org/x/sys/unix/
$ go build
can't load package: package gopath/src/golang.org/x/sys/unix: code in directory /tmp/issue-32621/src/gopath/src/golang.org/x/sys/unix expects import "golang.org/x/sys/unix"

@FiloSottile Should we just add a warning about this unsupported configuration (and fix the GCC default prefix) or try to find the root cause?

Let's just detect it early, print a helpful error, and exit.

@FiloSottile We can't exit. The go build process and as well as some internal test cases change GOPATH to be a subdirectory of GOROOT and expects it to work. So should it just print a helpful warning?

Which part of the build process, and what tests? It seems weird to rely on an unsupported and apparently broken configuration.

qbradq@qbradq-AB350-Gaming:~/godev/goroot/src$ ./all.bash
Building Go cmd/dist using /usr/lib/go-1.10.
Building Go toolchain1 using /usr/lib/go-1.10.
Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1.
Building Go toolchain2 using go_bootstrap and Go toolchain1.
go: GOPATH (/home/qbradq/godev/goroot/pkg/obj/gopath) under GOROOT (/home/qbradq/godev/goroot) is not supported
go tool dist: FAILED: /home/qbradq/godev/goroot/pkg/tool/linux_amd64/go_bootstrap install -gcflags=all= -ldflags=all= -i cmd/asm cmd/cgo cmd/compile cmd/link: exit status 2

Building toolchain2 apparently uses this configuration.

For an example of a test that uses this, see

@qbradq, can you get things to work by narrowing the check to GOROOT/src rather than all of GOROOT?

This was going to be my next try :) Unfortunately I broke my hand. That slowed me down. The Go build and test cases are all going to be under $GOROOT/src though, so it doesn't help.

Timed out. If the issue reoccurs please open a fresh report.