7 ms·

Cross-compiling with cgo can be frustrating at times, at least in my own experience. Since Ebitengine is a game engine, and they made this repository, I am pres

Cross-compiling with cgo can be frustrating at times, at least in my own experience. Since Ebitengine is a game engine, and they made this repository, I am presuming it's related.

bornfreddy 4y ago
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?
- cowl 4y ago
  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.
  - bornfreddy 4y ago
    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.
    - sangnoir 4y ago
      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
- steeleduncan 4y ago
  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.
jedisct1 4y ago
Using Zig is the easiest way to cross-compile with cgo: https://lucor.dev/post/cross-compile-golang-fyne-project-using-zig/ https://lucor.dev/post/cross-compile-golang-fyne-project-usi...
- emidoots 4y ago
  I am in love with Zig (as you know), but feel the need to say: please be careful with blanket claims like this. purego is a pretty admirable approach to fixing cgo cross-compilation without Zig (though has its own drawbacks, like no static binary for example.) Using Zig for Go cross-compilation, although quite great, isn't bulletproof. Finding the right CC/CXX incantation can be fairly tricky, the articles on this are not super up-to-date, and you need a copy of the macOS SDK[0] if you intend to cross-compile for macOS. You may also run into a few scary linker warnings and need to figure out the right Go build flags. I definitely think Zig and Go can be best-friends, after all they share so many similar qualities and seem quite complementary to each-other. It's definitely possible to get Go<->Zig CGO cross compilation working (I did so for Sourcegraph); But Zig needs a little more love before it'll 'just work' as claimed for the Go use case, so best not to claim otherwise until then. [0] https://github.com/ziglang/zig/issues/1349 https://github.com/ziglang/zig/issues/1349

Cross-compiling with cgo can be frustrating at times, at least in my own experience. Since Ebitengine is a game engine, and they made this repository, I am presuming it's related.

bornfreddy 4y ago

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?

cowl 4y ago
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.
- bornfreddy 4y ago
  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.
  - sangnoir 4y ago
    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
steeleduncan 4y ago
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.

jedisct1 4y ago

Using Zig is the easiest way to cross-compile with cgo: https://lucor.dev/post/cross-compile-golang-fyne-project-using-zig/ https://lucor.dev/post/cross-compile-golang-fyne-project-usi...

emidoots 4y ago
I am in love with Zig (as you know), but feel the need to say: please be careful with blanket claims like this. purego is a pretty admirable approach to fixing cgo cross-compilation without Zig (though has its own drawbacks, like no static binary for example.) Using Zig for Go cross-compilation, although quite great, isn't bulletproof. Finding the right CC/CXX incantation can be fairly tricky, the articles on this are not super up-to-date, and you need a copy of the macOS SDK[0] if you intend to cross-compile for macOS. You may also run into a few scary linker warnings and need to figure out the right Go build flags. I definitely think Zig and Go can be best-friends, after all they share so many similar qualities and seem quite complementary to each-other. It's definitely possible to get Go<->Zig CGO cross compilation working (I did so for Sourcegraph); But Zig needs a little more love before it'll 'just work' as claimed for the Go use case, so best not to claim otherwise until then. [0] https://github.com/ziglang/zig/issues/1349 https://github.com/ziglang/zig/issues/1349