Why not set up GOROOT again? I recommend reading two English articles. I translated them freely and put them in one.

The first post was about how to set up GOROOT before Go 1.10, published in 2013. The second article is from Go 1.10, how to deal with GOROOT, in 2018, the Go source submission log. This one is very short.

After reading this, you’ll find that, for the most part, you won’t need to manually set up GOROOT.

The first paper

Author: Dave Cheney | address: you dont need – – to – set – goroot – really

A short article explaining why you don’t need to set up GOROOT when compiling and using Go.

Summary introduction

In general, after Go 1.0, GOROOT is no longer required to be set up to compile and use Go. In fact, if you have multiple versions of the Go locale on your computer, setting up GOROOT can cause some problems.

GOPATH still needs to be set up.

GOPATH has been highly recommended since Go 1.0. With the release of Go 1.1, GOPATH is mandatory.

Why not set it againGOROOT?

Talk about the history of Go environment variables!

Go old-timers may remember that Go used to have to set up GOOS and GOARCH as well as GOROOT. GOROOT was set up because Make introduced the GOROOT content during the build and set GOROOT as their base path.

With the introduction of go Tool, GOOS and GOARCH became optional prior to Go 1.0, as build scripts automatically detected system categories and CPU architectures. With the release of Go 1.0 and the introduction of CMD/Dist bootstraved build tools, GOOS and GOARCH are truly optional and only available for cross-compilation.

I don’t need to set it upGOOS 和 GOARCHthatGOROOT?

GOROOT is defined to specify the root directory where GO is installed. In previous makefiles, it was used as the base path when other makefiles were introduced. Also, after Go 1.0, Go Tool uses it to find the Go compiler (stored in $GOROOT/ PKG /tool/$GOOS_$GOARCH) and the standard library (stored in $GOROOT/ PKG /$GOOS_$GOARCH). If you are a Java developer, you can think of GOROOT as JAVA_HOME.

The source code compiles to Go, which GOROOT will automatically discover (the parent directory of all.bash) and then set to Go toolchain.

Run the following command to check:

$ echo $GOROOT

$ go env
/home/dfc/go
Copy the code

A binary package downloaded from Golang.org or a system-installed Go environment also has the correct GOROOT set up in the toolchain.

An example, such as Ubutun 12.04, has Go 1.0 installed.

$ dpkg -l golang-{go,src} | grep ^ii
$ go
/usr/bin/go
$ go env GOROOT
/usr/lib/go
Copy the code

We can see that the Go toolchain is installed in /usr/bin/go, and GOROOT is built in /usr/lib/go

Why shouldn’t it be setGOROOT

We shouldn’t set GOROOT because the Go toolchain already has the correct values built in.

Setting GOROOT overrides the default values stored in the GO toolchain, potentially causing GO to execute different versions of the compiler and standard library files.

In both cases, you need to set up GOROOT. This is described in the official installation guide.

• If you are a Linux, FreeBSD, or OS X user, download the zip and tarball binary installation environment. The default environment for these binaries is /usr/local/go, where you are advised to install GO. If you choose not to do so, you must set it to the directory you specify.
• If you are a Windows user, use the zip binary package to install, the defaultGOROOTIn the C:\Go directory. If you install Go elsewhere, set itGOROOTTo the specified directory.

Other details

This article has shown how GOROOT is automatically discovered when compiling the Go environment from source code. But what if GOROOT doesn’t match the location of all.bash? For example, if you compile the Go environment in a temporary directory, how do you set up GOROOT correctly? The answer is to use GOROOT_FINAL, which will be used to override the automatically discovered GOROOT, set up in the GO toolchain.

For example, on Debian/Ubuntu, the builder sets the value of GOROOT_FINAL to /usr/lib/go. Leave GOROOT unset so that the build builds happily. Once the build is complete, install the Go toolchain to /usr/bin and install the compiler, source code, and packages to /usr/lib/go.

Pay attention to the point

There are special cases that need to be handled if you install the Go environment using binary packages, which have been described in this article.

Although the build system can detect this automatically, if the parent directory of all.bash does not meet GOROOT requirements, it will need to be handled separately.

The second article

Executable to find GOROOT

Start with Go 1.10 and find GOROOT using use OS.executable.

Previously, we built GOROOT using a make.sh compilation, but moving the entire directory to a new path would make the Go toolchain not work properly.

How to solve this problem?

One is that you can recompile the source, but that may not be possible if the new location is in another user’s directory.

The second is to set the GOROOT environment variable, but setting GOROOT is not recommended because it may cause go tool in one environment to use compile in another environment.

This time, go Tool determines GOROOT relative to the path, using the os.execute function. It also checks for the existence of the $GOROOT/ PKG /tool directory to avoid either of the following.

$ ln -s $GOROOT/bin/go /usr/local/bin/go
Copy the code

and

$ PATH=$HOME/bin:$PATH
$ GOPATH=$HOME
$ ln -s $GOROOT/bin/go $HOME/bin/go
Copy the code

In addition, if the current execution path is not under GOROOT, the soft link will find the location of the real command and check whether the path is GOROOT.

---