MinimumRequirements.md - wiki - Git at Google

 ---
 title: Minimum Requirements
 ---

 This page lists known minimum requirements for different operating systems and architectures.
 In line with the [Porting Policy, support for old operating system and architecture versions](/wiki/PortingPolicy#removing-old-operating-system-and-architecture-versions)
 may be removed in newer releases.
 Announcements for end of support are tracked in:
 [issue 23011 for macOS](https://go.dev/issue/23011),
 [issue 52188 for Windows](https://go.dev/issue/52188),
 and [issue 60792 for Linux](https://go.dev/issue/60792).

 ## Operating Systems

 ### [Linux](Linux)

 For Go 1.24 and later: Kernel version 3.2 or later.

 We don't support CentOS 5. The kernel is too old (2.6.18).

 For little-endian MIPS64, kernel version [4.1 is known to fail, and 4.8 works](https://go.dev/issue/16848).

 For loong64, kernel 5.19 and later versions work fine.

 For the tinyconfig (i.e., `make tinyconfig`) Linux configuration for embedded systems, you must also enable `CONFIG_FUTEX` and `CONFIG_EPOLL`.

 The [QEMU user space emulator](https://www.qemu.org/docs/master/user/main.html) is an alternative implementation of the Linux system call interface used to enable running binaries from emulated architectures without emulating a full Linux kernel. [Docker multi-platform builds](https://docs.docker.com/build/building/multi-platform/) often use the QEMU user space emulator. The QEMU user space emulator is not an officially supported platform, as it is not actually Linux. QEMU versions prior to 7.1.0 have [known issues](/issue/77572). If you encounter issues while using QEMU, see if the issue reproduces (a) with native Linux, and (b) on newer versions of QEMU.

 On arm64, an out of date (lower than version 2.33) ld.gold may cause shared library tests to fail (see [issue 28334](https://github.com/golang/go/issues/28334)).

 ### [Windows](Windows)

 For Go 1.21 and later: Windows 10 and higher or Windows Server 2016 and higher.

 ### [macOS (née OS X, aka Darwin)](Darwin)

 For Go 1.27 and later: macOS 13 Ventura or newer; see https://go.dev/doc/go1.26#darwin.
 For Go 1.26 and Go 1.25: macOS 12 Monterey or newer; see https://go.dev/doc/go1.25#darwin.

 We have builders for macOS 12 through macOS 26 as of 2026-03-10.

 ### [OpenBSD](OpenBSD)

 The current officially supported -stable versions only.

 ### [DragonFly BSD](DragonFly-BSD)

 Generally only the latest release version. We have a builder, but it's not the most stable of our ports.

 ### [FreeBSD](FreeBSD)

 See [Go on FreeBSD](/wiki/FreeBSD#go-on-freebsd) for supported FreeBSD/Architecture/Go versions matrix.

 ### [NetBSD](NetBSD)

 There are known NetBSD bugs (including kernel crashes) up to the current NetBSD 7.1. There is a reported fix in NetBSD 7.1.1 but it's unverified as of 2017-07-10, as we're not running builders again yet. See https://tip.golang.org/doc/go1.9#known_issues and https://github.com/golang/go/issues/20852

 ### [Solaris](Solaris)

 illumos (former OpenSolaris 10) based distributions or Oracle Solaris 11+.

 ### iOS

 iOS 12 or later.

 ## Architectures

 ### Microarchitecture support

 For some architectures, Go supports compiling to specific microarchitectures using environment variables, e.g. GOAMD64 for go1.18 and later. Binaries will check at startup whether the requested microarchitecture level is supported. For example, a binary built with `GOAMD64=v3` will fail on a CPU that doesn't have LZCNT support.

 Various microarchitecture levels and the environment variables used to select them are described with each architecture.

 The build cache understands the microarchitecture environment variables and does not require any cleaning if you change them.

 While performance is expected to improve when a higher minimum microarchitecture is requested, this might not be true in all cases. Benchmark your performance-critical code to verify performance improvements.

 ### amd64

 Until Go 1.17, the Go compiler always generated x86 binaries that could be executed by any 64-bit x86 processor.

 Go 1.18 introduced [4 architectural levels](https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels) for AMD64.
 Each level differs in the set of x86 instructions that the compiler can include in the generated binaries:

 - GOAMD64=v1 (default): The baseline. Exclusively generates instructions that all 64-bit x86 processors can execute.
 - GOAMD64=v2: all v1 instructions, plus CMPXCHG16B, LAHF, SAHF, POPCNT, SSE3, SSE4.1, SSE4.2, SSSE3.
 - GOAMD64=v3: all v2 instructions, plus AVX, AVX2, BMI1, BMI2, F16C, FMA, LZCNT, MOVBE, OSXSAVE.
 - GOAMD64=v4: all v3 instructions, plus AVX512F, AVX512BW, AVX512CD, AVX512DQ, AVX512VL.

 Setting, for example, GOAMD64=v3, will allow the Go compiler to use AVX2 instructions in the generated binaries (which may improve performance in some cases); but these binaries will not run on older x86 processors that don't support AVX2.

 The Go toolchain may also generate newer instructions, but guarded by dynamic checks to ensure they're only executed on capable processors. For example, with GOAMD64=v1, [math/bits.OnesCount](https://pkg.go.dev/math/bits#OnesCount) will still use the [POPCNT](https://www.felixcloutier.com/x86/popcnt) instruction if [CPUID](https://www.felixcloutier.com/x86/cpuid) reports that it's available. Otherwise, it falls back to a generic implementation.

 The Go toolchain does not currently generate any AVX512 instructions.

 The race detector is not supported on platforms that do not provide SSE3.

 Note that _processor_ is a simplification in this context. In practice, support from the entire system (firmware, hypervisor, kernel) is needed.

 See section [Microarchitecture support](#microarchitecture-support) for hints on how to use microarchitecture environment variables like GOAMD64.

 ### 386

 See https://go.dev/doc/install/source#environment

 - GO386=sse2 (default): Any processor with at least SSE2
 - GO386=softfloat: All Pentium MMX or later processors (uses software floating point emulation)

 ### arm

 See https://go.dev/doc/install/source#environment

 - GOARM=5: use software floating point; when CPU doesn't have VFP co-processor
 - GOARM=6: use VFPv1 only; default if cross compiling; usually ARM11 or better cores (VFPv2 or better is also supported)
 - GOARM=7: use VFPv3; usually Cortex-A cores

 ### arm64

 Until Go 1.23, the Go compiler always generated ARM64 binaries that could be executed by any ARMv8-A processor.

 Go 1.23 introduced a new `GOARM64` environment variable, which specifies the minimum target version of the ARM64 architecture at compile time. Allowed values are `v8.{0-9}` and `v9.{0-5}`. This may be followed by an option specifying extensions implemented by target hardware. Valid options are `,lse` and `,crypto`.

 Setting, for example, `GOARM64=v8.0,lse`, will allow the Go compiler to use LSE instructions in the generated binaries (which may improve performance in some cases); but these binaries will not run on older ARM64 processors that don’t support LSE.

 The Go toolchain may also generate newer instructions, but guarded by dynamic checks to ensure they’re only executed on capable processors.

 The `GOARM64` environment variable defaults to `v8.0`.

 ### ppc64 (big endian)

 POWER8 and above.

 Prior to Go 1.9, POWER5 and newer processors were supported.

 Starting with Go 1.9, only POWER8 and above are supported.

 Starting with Go 1.27, the linux target ABI has changed from ELFv1 to ELFv2. This change requires a kernel which supports loading ELFv2 binaries.

 Starting with Go 1.27, the linux target supports external linking, cgo, and PIE buildmodes. These features require an ELFv2 userspace.

 ### ppc64le (little endian)

 POWER8 and above.

 ### mips64 (big endian)

 MIPS III or higher. Builder is using MIPS64r2.

 ### mips64le (little endian)

 MIPS III or higher in little endian mode.

 ### s390x

 z13

 ### mips (big endian) and mipsle (little endian)

 MIPS32r1

 ### riscv64

 rv64g (rv64imafd).
 Starting from Go 1.23, RVA20U64 mandatory extensions is required.

 ### loong64

 Go 1.19 or above. the Go compiler always generated Loong64 binaries that could be executed any processor cored by LA364, LA464, LA664 or later.

 - LA364: Supports unaligned memory access, 128-bit SIMD, typical processors include loongson-2K2000/2K3000, etc.
 - LA464: Supports unaligned memory access, 128/256-bit SIMD, typical processors include loongson-3A5000/3C5000/3D5000, etc.
 - LA664: Supports unaligned memory access, 128/256-bit SIMD, typical processors include loongson-3A6000/3C6000, etc.

 ## cgo

 For programs using cgo, gcc 4.6 or newer is required.

 Starting with Go 1.25, use of CGO on Windows requires a C compiler that incorporates support for DWARF 5.
 For those using GCC, this requirement translates to selecting a version of GCC built with binutils version 2.37 or later.
 Programs built with older versions of GCC (those using binutils 2.36 and earlier) will produce non-working executables, see [issue 75077](https://github.com/golang/go/issues/75077) for details.

 ## Tools

 ### Git

 For Go 1.25 or later: Git version 2.24.0 or later.
	---
	title: Minimum Requirements
	---

	This page lists known minimum requirements for different operating systems and architectures.
	In line with the [Porting Policy, support for old operating system and architecture versions](/wiki/PortingPolicy#removing-old-operating-system-and-architecture-versions)
	may be removed in newer releases.
	Announcements for end of support are tracked in:
	[issue 23011 for macOS](https://go.dev/issue/23011),
	[issue 52188 for Windows](https://go.dev/issue/52188),
	and [issue 60792 for Linux](https://go.dev/issue/60792).

	## Operating Systems

	### [Linux](Linux)

	For Go 1.24 and later: Kernel version 3.2 or later.

	We don't support CentOS 5. The kernel is too old (2.6.18).

	For little-endian MIPS64, kernel version [4.1 is known to fail, and 4.8 works](https://go.dev/issue/16848).

	For loong64, kernel 5.19 and later versions work fine.

	For the tinyconfig (i.e., `make tinyconfig`) Linux configuration for embedded systems, you must also enable `CONFIG_FUTEX` and `CONFIG_EPOLL`.

	The [QEMU user space emulator](https://www.qemu.org/docs/master/user/main.html) is an alternative implementation of the Linux system call interface used to enable running binaries from emulated architectures without emulating a full Linux kernel. [Docker multi-platform builds](https://docs.docker.com/build/building/multi-platform/) often use the QEMU user space emulator. The QEMU user space emulator is not an officially supported platform, as it is not actually Linux. QEMU versions prior to 7.1.0 have [known issues](/issue/77572). If you encounter issues while using QEMU, see if the issue reproduces (a) with native Linux, and (b) on newer versions of QEMU.

	On arm64, an out of date (lower than version 2.33) ld.gold may cause shared library tests to fail (see [issue 28334](https://github.com/golang/go/issues/28334)).

	### [Windows](Windows)

	For Go 1.21 and later: Windows 10 and higher or Windows Server 2016 and higher.

	### [macOS (née OS X, aka Darwin)](Darwin)

	For Go 1.27 and later: macOS 13 Ventura or newer; see https://go.dev/doc/go1.26#darwin.
	For Go 1.26 and Go 1.25: macOS 12 Monterey or newer; see https://go.dev/doc/go1.25#darwin.

	We have builders for macOS 12 through macOS 26 as of 2026-03-10.

	### [OpenBSD](OpenBSD)

	The current officially supported -stable versions only.

	### [DragonFly BSD](DragonFly-BSD)

	Generally only the latest release version. We have a builder, but it's not the most stable of our ports.

	### [FreeBSD](FreeBSD)

	See [Go on FreeBSD](/wiki/FreeBSD#go-on-freebsd) for supported FreeBSD/Architecture/Go versions matrix.

	### [NetBSD](NetBSD)

	There are known NetBSD bugs (including kernel crashes) up to the current NetBSD 7.1. There is a reported fix in NetBSD 7.1.1 but it's unverified as of 2017-07-10, as we're not running builders again yet. See https://tip.golang.org/doc/go1.9#known_issues and https://github.com/golang/go/issues/20852

	### [Solaris](Solaris)

	illumos (former OpenSolaris 10) based distributions or Oracle Solaris 11+.

	### iOS

	iOS 12 or later.

	## Architectures

	### Microarchitecture support

	For some architectures, Go supports compiling to specific microarchitectures using environment variables, e.g. GOAMD64 for go1.18 and later. Binaries will check at startup whether the requested microarchitecture level is supported. For example, a binary built with `GOAMD64=v3` will fail on a CPU that doesn't have LZCNT support.

	Various microarchitecture levels and the environment variables used to select them are described with each architecture.

	The build cache understands the microarchitecture environment variables and does not require any cleaning if you change them.

	While performance is expected to improve when a higher minimum microarchitecture is requested, this might not be true in all cases. Benchmark your performance-critical code to verify performance improvements.

	### amd64

	Until Go 1.17, the Go compiler always generated x86 binaries that could be executed by any 64-bit x86 processor.

	Go 1.18 introduced [4 architectural levels](https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels) for AMD64.
	Each level differs in the set of x86 instructions that the compiler can include in the generated binaries:

	- GOAMD64=v1 (default): The baseline. Exclusively generates instructions that all 64-bit x86 processors can execute.
	- GOAMD64=v2: all v1 instructions, plus CMPXCHG16B, LAHF, SAHF, POPCNT, SSE3, SSE4.1, SSE4.2, SSSE3.
	- GOAMD64=v3: all v2 instructions, plus AVX, AVX2, BMI1, BMI2, F16C, FMA, LZCNT, MOVBE, OSXSAVE.
	- GOAMD64=v4: all v3 instructions, plus AVX512F, AVX512BW, AVX512CD, AVX512DQ, AVX512VL.

	Setting, for example, GOAMD64=v3, will allow the Go compiler to use AVX2 instructions in the generated binaries (which may improve performance in some cases); but these binaries will not run on older x86 processors that don't support AVX2.

	The Go toolchain may also generate newer instructions, but guarded by dynamic checks to ensure they're only executed on capable processors. For example, with GOAMD64=v1, [math/bits.OnesCount](https://pkg.go.dev/math/bits#OnesCount) will still use the [POPCNT](https://www.felixcloutier.com/x86/popcnt) instruction if [CPUID](https://www.felixcloutier.com/x86/cpuid) reports that it's available. Otherwise, it falls back to a generic implementation.

	The Go toolchain does not currently generate any AVX512 instructions.

	The race detector is not supported on platforms that do not provide SSE3.

	Note that _processor_ is a simplification in this context. In practice, support from the entire system (firmware, hypervisor, kernel) is needed.

	See section [Microarchitecture support](#microarchitecture-support) for hints on how to use microarchitecture environment variables like GOAMD64.

	### 386

	See https://go.dev/doc/install/source#environment

	- GO386=sse2 (default): Any processor with at least SSE2
	- GO386=softfloat: All Pentium MMX or later processors (uses software floating point emulation)

	### arm

	See https://go.dev/doc/install/source#environment

	- GOARM=5: use software floating point; when CPU doesn't have VFP co-processor
	- GOARM=6: use VFPv1 only; default if cross compiling; usually ARM11 or better cores (VFPv2 or better is also supported)
	- GOARM=7: use VFPv3; usually Cortex-A cores

	### arm64

	Until Go 1.23, the Go compiler always generated ARM64 binaries that could be executed by any ARMv8-A processor.

	Go 1.23 introduced a new `GOARM64` environment variable, which specifies the minimum target version of the ARM64 architecture at compile time. Allowed values are `v8.{0-9}` and `v9.{0-5}`. This may be followed by an option specifying extensions implemented by target hardware. Valid options are `,lse` and `,crypto`.

	Setting, for example, `GOARM64=v8.0,lse`, will allow the Go compiler to use LSE instructions in the generated binaries (which may improve performance in some cases); but these binaries will not run on older ARM64 processors that don’t support LSE.

	The Go toolchain may also generate newer instructions, but guarded by dynamic checks to ensure they’re only executed on capable processors.

	The `GOARM64` environment variable defaults to `v8.0`.

	### ppc64 (big endian)

	POWER8 and above.

	Prior to Go 1.9, POWER5 and newer processors were supported.

	Starting with Go 1.9, only POWER8 and above are supported.

	Starting with Go 1.27, the linux target ABI has changed from ELFv1 to ELFv2. This change requires a kernel which supports loading ELFv2 binaries.

	Starting with Go 1.27, the linux target supports external linking, cgo, and PIE buildmodes. These features require an ELFv2 userspace.

	### ppc64le (little endian)

	POWER8 and above.

	### mips64 (big endian)

	MIPS III or higher. Builder is using MIPS64r2.

	### mips64le (little endian)

	MIPS III or higher in little endian mode.

	### s390x

	z13

	### mips (big endian) and mipsle (little endian)

	MIPS32r1

	### riscv64

	rv64g (rv64imafd).
	Starting from Go 1.23, RVA20U64 mandatory extensions is required.

	### loong64

	Go 1.19 or above. the Go compiler always generated Loong64 binaries that could be executed any processor cored by LA364, LA464, LA664 or later.

	- LA364: Supports unaligned memory access, 128-bit SIMD, typical processors include loongson-2K2000/2K3000, etc.
	- LA464: Supports unaligned memory access, 128/256-bit SIMD, typical processors include loongson-3A5000/3C5000/3D5000, etc.
	- LA664: Supports unaligned memory access, 128/256-bit SIMD, typical processors include loongson-3A6000/3C6000, etc.

	## cgo

	For programs using cgo, gcc 4.6 or newer is required.

	Starting with Go 1.25, use of CGO on Windows requires a C compiler that incorporates support for DWARF 5.
	For those using GCC, this requirement translates to selecting a version of GCC built with binutils version 2.37 or later.
	Programs built with older versions of GCC (those using binutils 2.36 and earlier) will produce non-working executables, see [issue 75077](https://github.com/golang/go/issues/75077) for details.

	## Tools

	### Git

	For Go 1.25 or later: Git version 2.24.0 or later.