HOWTO: Cross-compile a Go app for Windows from Linux

I recently needed to test some app on windows, and while cross-compiling in Go is straight-forward, the app had some C code and apparently on Arch Linux the mingw64-gcc package is misconfigured.

After some head scratching I figured out a workaround until the package is fixed (task #4313), you have to link your Go code against ssp.

note this bug is specific to Arch Linux, however other distros might build the toolchain in the same manner.

Building the toolchain:

1. Download and unpack the Go source code:

note this guide assumes $GOROOT is set to /usr/src/go/.

  • Use mercurial (slow) hg clone -u release https://code.google.com/p/go
  • Use the source tarball from golang.org

1a. (optional but recommended) add export PATH="$PATH:$GOROOT/bin" to your ~/.bashrc (or the equivalent file for your shell).

2. Compiling the native toolchain:

3. Compiling the Windows toolchain without CGO:

Repeat with GOARCH=amd64 if you want to build win64 binaries.

4. Compiling the Windows toolchain with CGO support:

  • Install mingw-w64-gcc

Repeat with GOARCH=amd64 CC_FOR_TARGET="x86_64-w64-mingw32-gcc .... if you want to build win64 binaries.

note that once the bug is fixed, you can remove -fno-stack-protector -D_FORTIFY_SOURCE=0 -lssp from CC_FOR_TARGET.

Actually compiling your code to run on windows:

We use the same environment variables from earlier, except we have to replace CC_FOR_TARGET with CC

Code:

Testing:

note that to build native go with cgo you will have to use env CC=gcc go build


Generating new bson.ObjectId with a Specific timestamp.

For a project I'm working on, using the excellent mgo driver, I needed to be able to query the MongoDB collection by the ObjectId's timestamp.

And while I was inserting dummy data, I had no obvious way to generate a new unique ObjectId with a timestamp (the timestamp itself wasn't unique) so I wrote this little helper function.

Note that this function isn't the same as bson.NewObjectIdWithTime, bson.NewObjectIdWithTime works for generating a timestamp-only ObjectId that you can query the database with, but not for insertion.
Continue reading


The performance of using interface{} vs a specific type.

I've recently started learning Go, and I have to say I'm very amazed by the whole concept of Goroutines, specially coming from a NodeJS / C++ background.

But sometimes it's nice to have a variable with a dynamic type, which Go does support (aka interface{}) , then I started wondering about the performance of using it vs just using one specific type.

I wrote a simple benchmark, at first I was rather disappointed at how slow it was compared to using the direct type, then I tried using goroutines to speed it up, with both buffered and unbuffered channels, surprisingly it didn't help at all, it even slowed it down farther.

Since the benchmark is simply summing some numbers, I decided to try atomic.AddUint64(), and while it was a tiny bit slower for defined types, it was much faster using interface{}

Continue reading