Skip to content
Neil O'Toole edited this page Mar 15, 2020 · 1 revision

Why does xcgo exist?

It's hard to do CGo cross-compilation. Speaking as of 2020-03-14, if you want to do go1.14 releases using the full capabilities of goreleaser, there doesn't seem to be anything else out there . In particular, releasing a snap is a PITA. For snap, you basically should start with an Ubuntu-based image (as opposed to most golang-related images, which are Debian).

Case in point: the goreleaser page for CGo states: "Unfortunately, GoReleaser does not support CGO".

It shouldn't be this hard.

I don't think that CGo is that much of a rare beast that it should be so tricky. IMHO, every Go development effort should be able to at least consider using SQLite, without being scared off by the build / dist hassles involved.

Again IMHO, being that there's an official golang:latest docker image, I could envision an official golang-xcgo:latest image that provides the basics of what this image does. I wouldn't expect such an image to include everything that neilotoole/xcgo does, such as goreleaser or mage, or snapcraft. That would imply "blessing" those third-party efforts as somewhat official, and I firmly agree with the Go team's approach of generally being conservative in expanding the language or toolchain.

Why is the xcgo image so big?

There's a lot going on. If you're releasing a multi-platform CGO-enabled project, you probably aren't really worried about this. But pull requests to slim the image are welcome.

What about arm, 32-bit etc?

The aim of xcgo is to support pretty much every even-somewhat-common Go/CGo release use case. Send a pull request or open an issue.

Clone this wiki locally