Snapcraft --target-arch not producing cross platform snaps with Golang


#1

I tried various options and noticed that with base: core18 used as advised in the docs I’m not able to create snaps for non-amd64 architecture when using Golang. If I don’t use base: core or core18, the build fails and I’m also not able to use the latest go 1.12.1 for some reason. Here is my snapcraft yaml file: https://github.com/apache/cloudstack-cloudmonkey/blob/master/snap/snapcraft.yaml

Any help and advice is welcome on how to build and publish cross architecture binaries with the Go plugin?


#2

I think your issue here is because in your override-build snippet you have this:

      go build -mod=vendor -ldflags="-s -w -X main.GitSHA=$(git rev-parse --short HEAD) -X main.BuildDate=$(date +%FT%T%z)" -o cmk cmk.go

This will always build for the current architecture that go is running on, in order to enable cross-compiling with go, you would need to set the environment variables GOARCH, GOOS, and if on armhf GOARM. Though note the GOOS doesn’t really matter since snaps only build and run on linux (even if running from mac/windows using multipass as that’s really a linux VM) so that will always be the same.

The standard go plugin will do this for you, setting the appropriate values of the environment variables when it calls go build. However, since you need to set some additional options to the go build call it seems, you will need to set these environment variables yourself similar to something like:

parts:
  cloudmonkey:
     ... your other stuff here ...
    override-build: |
      case $SNAPCRAFT_ARCH_TRIPLET in
        arm-linux-*)
          export GOARCH=arm
          export GOARM=7
          ;;
        x86_64*)
          export GOARCH=amd64
          ;;
        # TODO add other arches
      esac
      GO111MODULE=on go build -mod=vendor -ldflags="-s -w -X main.GitSHA=$(git rev-parse --short HEAD) -X main.BuildDate=$(date +%FT%T%z)" -o cmk cmk.go

Note that I explicitly set GO111MODULE=on, that may or may not be necessary for you…


#3

Thanks @ijohnson I’ll try your workaround.