Go: Difference between revisions

[https://golang.org/ Go] is a statically-typed language with syntax loosely derived from that of C, adding garbage collected memory management, type safety, some dynamic-typing capabilities, additional built-in types such as variable-length arrays and key-value maps, and a large standard library.

`buildGoModule` uses the version of Go that's included in `nixpkgs` to build the software.

To build for a specific version of Go, you may need to find the appropriate `pkgs.buildGoXXXModule` function to use.

This function may not be present in the version of nixpkgs that you're using, for example, `buildGo122Module` is not available in `github:NixOS/nixpkgs/nixos-23.05`, but is available in `github:NixOS/nixpkgs/nixos-unstable`.

By default, `buildGoModule` will attempt to build the `main` package that's in the root of the source code location.

However, it's a common pattern in Go applications to have binaries within the `./cmd/binary-name` directory instead.

Setting the `subPackages` attribute to be a list of the packages to build supports this pattern.

The following `flake.nix` demonstrates how to build a Go module, where the source code is located in Github. To use it, copy this file as `flake.nix` into an empty directory on your computer, and run `nix build`. Nix will download the source code, including dependencies, and produce a `./result` folder containing a `ziti` binary.

Running `nix shell` will create a shell, where you can execute the `ziti` binary.<syntaxhighlight lang="nix">

         default = pkgs.buildGo122Module {

           name = "openziti";

             rev = "v1.0.0";

If you want to build a local project with Nix, replace the `src` attribute to be the local directory, e.g.:<syntaxhighlight lang="nix">

On NixOS, include files and libraries aren't kept in a system-wide search path. If a Go program uses cgo and attempts to include C header files, or link against libraries, compilation is likely to fail.

For example, suppose a Go program includes <tt>&lt;sys/capability.h&gt;</tt> (provided by <tt>libcap</tt>), and links against <tt>libcap</tt>. To obtain an environment in which the program can be compiled, run:

If you encounter [https://github.com/go-delve/delve/issues/3085 this issue] and receive an error about _FORTIFY_SOURCE when running delve (for example in VSCode), put <tt>hardeningDisable = [ "fortify" ];</tt> inside shell.nix or in the <tt>mkShell</tt> invocation argument like this:

If <code>go build -ldflags "-s -w -linkmode external -extldflags -static"</code> fails on NixOS, with the error message <code>cannot find `-lpthread</code> and <code>cannot find -lc</code> - it is because the linker cannot find static glibc to link with. You need to have glibc.static in your environment (and have CFLAGS/LDFLAGS adjusted accordingly).

One way to achieve this is to have something like the following as <code>shell.nix</code> and run the compilation in a nix-shell:

Linking against glibc.static does not really work because glibc does not really like static linking. You get a warning like <code>warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking</code>. To really create a static build, use musl. Example based on buildGoModule example from documentation:

[[Category:Applications]]