It's my understanding that you have to do this on Linux as well, and it isn't enough to just build your project with CGO_ENABLED=0, you'll also have to rebuild the go-toolchain with CGO_ENABLED=0 for it to work. But perhaps this has changed in recent versions of go?

Eg:

    cd /tmp
    git clone git@github.com:apg/wipes.git wipes.git
    cd wipes.git/
    go get github.com/gorilla/websocket
    go get github.com/gorilla/websocket
    go build
    ldd wipes.git
    # > libc.so.6 among others
    export CGO_ENABLED=0
    go build  # makes no difference, produces identical binary

Afaik, in this case it's 'net/http' that pulls in a dependency on cgo (again, unless we rebuild the whole go toolchain with cgo_enabled=0).

Not that this is terrible as such, but it's a gotcha if you want to run the resulting binary in a chroot, or on a host with a different version of libc...

  > Afaik, in this case it's 'net/http' that pulls in a 
  > dependency on cgo (again, unless we rebuild the whole
  > go toolchain with cgo_enabled=0).

You can also build with '-tags netgo'[1], and use go for name resolution, but still use cgo for when else you may need it.

[1]: http://dominik.honnef.co/go-tip/2013-09-07/#netgo

Indeed:

    go install -a -tags netgo std
    go build -tags netgo
    ldd wipes.git
        not a dynamic executable

Thanks for the tip :)

> But perhaps this has changed in recent versions of go?

it hasn't. i meant 'if you build go with CGO_ENABLED=0' but was unclear.

TLS will work, you just can't pull the host CA bundle (osx keeps it in the keychain), so certificate verification won't work without proving your own.