Hacker News Reader

Comment by bornfreddy | Hacker News Reader

Curious - what is frustrating about it? I found the process very easy and with no weird bugs, but I only made a thin layer over a supplied C SDK, so maybe my use of cgo is not representative?

View on HN

Make sure you have the righ C cross compiler for the target platform. Then you might encounter the usuall Wrong version of libc etc. So it's not enough to compile for goos=linux for example but also need to make sure that your C cross-compiler has the right version of libc for the target machine or Statically link the version you want, or deploy inside a container etc etc.

Pure Go? don't need anything else beside the Go compiler.

If you can avoid CGO, Avoid it.

Ah, I see, thank you for the explanation. The reason I never had any problems of this kind is that I always compile Go in a container anyway, so the environment is controlled completely. Makes sense that using the C toolchain on the host would be painful, yes.

Setting up the cross-compiling toolchain is a pain in itself, to occasional dabblers and/or when your target is off the beaten track. I can trivially target MIPS-LE with `GOARCH=mipsle GOOS=linux`, but as soon as I added CGO into the mix to support SQLite, things went off the rail and I gave up after trying to set up a mips cross-compiling tool chain in a container

When cross compiling pure Go you set an environment variable, build, and you have a binary ready to run, it is trivial.

When cross compiling with cgo you need a C cross compiling toolchain for the target platform installed with the right libc, etc. It is not impossible and that is how C/C++ is always cross compiled, but it is much more hassle than compiling pure Go.

Reply on news.ycombinator.com