Gentoo go1.21.4 safe installation along with go1.20.4

I am new to go as a Gentoo Linux user. The current go in my Gentoo Workstation is of go1.20.4 which are depended by:

equery d go
 * These packages depend on go:
app-metrics/prometheus-2.43.0-r2 (>=dev-lang/go-1.18)
app-shells/fzf-0.39.0 (>=dev-lang/go-1.18)
dev-lang/go-1.20.4 (dev-lang/go)
dev-util/android-tools-34.0.0 (dev-lang/go)
dev-util/promu-0.14.0 (>=dev-lang/go-1.18)
sys-libs/libcap-2.69 (tools ? dev-lang/go)

In this case, I have no a normal way to install the latest go version of go1.21.4 to build some advanced network project. The official package had been downloaded and installed in “/usr/local/" by which I can only call the binary path /usr/local/go/bin/go to implement the building of target project. I have just read some basic tutorial in while I have not found the accurate description of my problem yet.

Please tell me the official and normal way to select the version of go compiler from local path like “/usr/local”.


Now I use makefile flexibly to call the go1.21.4 along with the Gentoo system go1.20. Are there any better method than makefile? I don’t confirm it’s robust to build the go project with local installed version of go with a makefile with specific $(GO), if you feel it’s flexible, please tell me.

Hi @Kocha_Saito, welcome to the forum.

There are several options available to install multiple versions of Go side-by-side.

The built-in method is go install:

$ go install
$ go1.18.3 download

The binary of this version can be invoked as go1.18.3.

For more convenience, several third-party tools allow managing Go versions, such as:

Read more details here: How to use multiple Go versions alongside each other

Respect Mr ChristophBerger,
Thanks for your nice advice. In my situation, there are some other go project which invoke as their builder where the go.mod contain different version of go. In the simplest case, I can deploy specific makefile to call different string path than go to invoke the customized installed version of go to build. While in most of the practical case, they use to build the project where it’s a little risky to replace the go by go1.xx.yy in the script I think.
For the third party ones, I prefer I can write a anaconda for go someday… Now my alternative to build the projects(with script) is to add line #export PATH="/usr/local/go/bin:$PATH" in ~/.bashrc or ~/.zshrc to overwrite the system path of go in Gentoo Linux based on the version I need in specific go project, which does not affect the Portage/emerge in my case, since we(gentoo user) switch as root to manage @world set in Portage in general.
Thanks for you nice advice again and best wish to communicate with you again
Faithfully me

Indeed, this is a special situation.

Two quick thoughts on this –

  1. Maybe direnv helps? This tool uses .envrc files to specify folder-specific environment settings. When you cd into such a folder, the settings in .envrc become active, when you cd out of the folder, the settings vanish. This could be a way of changing the Go path without messing with

  2. Go 1.21 is able to download the toolchains of newer Go versions if the go.mod file requires them. This way, whatever minimum Go version a go.mod file requires, the currently installed Go command would be able to compile that code. Unfortunately, you’d have to wait until Gentoo’s packages arrive at Go 1.21…

Thanks for your advice. I have complete the compile and test of those golang projects with my alternative. In Gentoo ways, there should be slots for go by which we can invoke

eselect list go
eselect set go NUMBER

to specify the emerged go in Gentoo Systems. I will try your advice in the deeper development loop in myself project.

Thanks Faithfully !!!

1 Like