'goenv install [version]' does nothing on aarch64 (ubuntu bionic-based linux)

[golyalpha]

I'm not sure why goenv doesn't do anything here, on aarch64. I've installed both rbenv and pyenv too, and pyenv is installing Python 3.8.0 for me on there right now, and I am pretty sure rbenv would be doing the same.

I tried running goenv install with verbose both on and off, and nothing gets printed out to the console.

Here's the goenv section of .bashrc:

export GOENV_ROOT="$HOME/.goenv"
export PATH="$GOENV_ROOT/bin:$PATH"
eval "$(goenv init -)"
export PATH="$GOROOT/bin:$PATH"
export PATH="$PATH:$GOPATH/bin"

[golyalpha]

Alright, I can now confirm that this is a aarch64-specific issue. Seeing the URL it is downloading, I can't help but wonder, is install actually building from source (like pyenv and rbenv do) or is it just downloading the binaries and unpacking them?

[cjmaria]

This is also occurring for me on macOS 11.2.1 on the aarch64 M1 chip.

[josvisser66]

Happening for me too :-/

[josvisser66]

Debugged this. The issue is that there is no pre-built package for the Go version you are installing. E.g:

goenv install 1.15.2

fails silently because https://golang.org/dl/ does not contain a pre-built binary package for that version. The way that the installation procedure works is unfortunately that this fails silently.

If you install a version for which a prebuilt package does exist (e.g. 1.16.3) then everything works swimmingly.

[golyalpha]

Yeah, I figured that was the case... Shame compiling go from sources is not as easy as "grabbing the sources and dependencies and running it through gcc".

[josvisser66]

Working on that now :-)

[hmijail]

Any plans to fix this?

I see people "fixing" it by running the x64 arch version, but I shudder to think the kind of breakage that might cause down the road - when libraries for one arch try to work with executables of another.

[golyalpha]

@hmijail I wouldn't be too worried about that. Other software would be hardcore broken on the M1 Macs if that were the case there. That being said, x64 emulation on generic arm (even arm64) is pretty slow, so, I'd avoid it if at all possible.

[hmijail]

But that's what already happens. See for example https://github.com/libsndfile/libsndfile/issues/852. Mixing architectures causes pain either directly at the linkage level, or indirectly at the expected paths level or build system level.

So I'd like to fix root causes instead of sowing weird breakage for later.

Re: emulation performance, the little I have checked myself wasn't actually a problem, either through macOS Rosetta or through Docker, so 🤷🏻

[golyalpha]

Yeah, but thankfully that's an issue at build configuration, not runtime.

Re: emulation performance - I was talking about generic arm, not ASi arm. Obviously, x64 emulation on Neoverse or ASi cores will run much better than the much more common Cortex-A cores.

[ChronosMasterOfAllTime]

#273 At least will notify you so it doesnt quietly exit

[ghost]

We can look into a new feature to compile from source (put behind some arg flag or prompt the user when no version for their Arch/OS is found)

[ChronosMasterOfAllTime]

Tracking this as a stretch goal for #342